sarah-walker-pcem / arculator Goto Github PK

It appears that by default, disc images are forced to conform to ADFS' 1024 cylinder limit when they are loaded. However some filesystems (e.g. ZIDEFS with the ICS card, or Armstrong Walker IDEFS with the HCCS A3000 card in PR #47) support multiple ADFS volumes on a larger, partitioned disc.

I modified these limits in my own build of Arculator, and it seems to function as expected - with my HCCS emulation, I can carve a 2GB image up into 4 512MB partitions, like I do with a flash disc on my real A3000. Given that this is a valid use case on original hardware, would it make sense to lift these limits, or at least add an "I know this is too big for ADFS and I want it anyway" option to bypass them?

When I try to use the AEH50 or AEH54 podules in Arculator on Linux using commit 323e1e2, starting up the machine will result in a segfault.

Relevant files:

• RISC iX.cfg
• arclog.txt

Debugging reveals that the segfault occurs at different places depending on the podule chosen:

• aeh50: The segfault occurs at line 1423 of podules/common/net/ne2000.c
• aeh54: The segfault occurs at line 534 of podules/aeh54/src/seeq8005.c

In both cases, the cause is similar: The net pointer (ne2000->net for aeh50, seeq8005->net for aeh54) is NULL.

It's quite possible there's something I haven't done that I need to do, so if this is the case, I apologise! The ROMs are in their correct locations, though, as far as I know. (podules/aeh50/EthernetII_ID_ROM.ROM and podules/aeh54/ether3.rom respectively)

I'm using gcc 11.2.1 to compile on Gentoo Linux.

If there's any more information you need, please let me know!

I've tried both Debian 10 and 11, get the below (or very similar) output:

config.log
make.log

Arculator's SLIRP interface appears to have a concurrency issue - the queue structure that it uses is not inherently thread-safe, and it is possible for the main Arculator thread to remove a packet from the queue before the SLIRP thread has finished inserting it, causing it to read bogus data and usually crash.

Any long-running heavy network activity should be able to replicate the issue, but the particular case that caused this for me was NFS activity on an emulated A440/1 under RISCiX. The chance of it occurring is still pretty low, but when reading a large file over NFS, I would usually hit it within 5 or so minutes.

I hacked a mutex into podules/common/net/net_slirp.c to serialise queue insertions and removals, and while I'm not sure if this is the only place where locking is necessary, it seems to have resolved the crashes I was seeing. Diff is below:

diff --git a/podules/common/net/net_slirp.c b/podules/common/net/net_slirp.c
index 58da9e6..ff1c05b 100644
--- a/podules/common/net/net_slirp.c
+++ b/podules/common/net/net_slirp.c
@@ -13,6 +13,8 @@ typedef struct net_slirp_t
        queueADT slirpq;
 } net_slirp_t;

+static pthread_mutex_t queue_mutex = PTHREAD_MUTEX_INITIALIZER;
+
 static void *slirp_poll_thread(void *p)
 {
        net_t *net = p;
@@ -47,7 +49,9 @@ static void *slirp_poll_thread(void *p)
 static int net_slirp_read(net_t *net, packet_t *packet)
 {
        net_slirp_t *slirp = net->p;
+       int ret = -1;

+       pthread_mutex_lock(&queue_mutex);
        if (QueuePeek(slirp->slirpq) > 0)
        {
                struct queuepacket *qp = QueueDelete(slirp->slirpq);
@@ -56,10 +60,11 @@ static int net_slirp_read(net_t *net, packet_t *packet)
                packet->data = qp->data;
                packet->len = qp->len;

-               return 0;
+               ret = 0;
        }

-       return -1;
+       pthread_mutex_unlock(&mutex);
+       return ret;
 }

 static void net_slirp_write(net_t *net, uint8_t *data, int size)
@@ -80,7 +85,9 @@ void slirp_output(const unsigned char *pkt, int pkt_len)
        p = (struct queuepacket *)malloc(sizeof(struct queuepacket));
        p->len = pkt_len;
        memcpy(p->data, pkt, pkt_len);
+       pthread_mutex_lock(&queue_mutex);
        QueueEnter(*g_slirpq, p);
+       pthread_mutex_unlock(&queue_mutex);
 //        aeh54_log("slirp_output %d @%d\n",pkt_len,p);
 }
 int slirp_can_output(void)

Minor issue, but thought I'd report since it might make some commits from those on non-Windows machines look weird. In a git checkout on Mac, I'm seeing a mix of line endings in different files, e.g.:

% file src/wx-app.cc
src/wx-app.cc: c program text, ASCII text
% file src/wx-sdl2-joystick.c
src/wx-sdl2-joystick.c: c program text, ASCII text, with CRLF line terminators

I'd guess this might be an artifact from the mercurial to git migration.

Configuring Git to handle line endings suggests setting git config --global core.autocrlf true on Windows. (I've confirmed my settings on Mac/Linux are the suggested git config --global core.autocrlf input.)

One potential option for fixing: Rewrite git history to replace all CRLF to LF?. This would break any outstanding pull requests though (workaround would be cherry-picking the individual commits.)

Firstly this is an amazing bit of work, congratulations to all involved. I've built the Linux version on a Lenovo Chromebook, it seems to work well, but the screen is obviously very small and I cant access the pop up menu to change the display size or load disks. The right click function doesn't seem to work.

Is this a known Linux issue ? If not is there anything I can change in the config file to load a floppy and make the screen bigger?

Thanks

Matt

To reproduce, configure Arculator to run an A5000, then select Video > Border size > Fixed (standard monitor) borders. Any VGA mode (e.g. 27, 31) will be scaled incorrectly, like this:

The "native borders" setting works fine in these modes. Looking at the code in vidc.c, I can see the three different branches of code that do scaling differently depending on the border size setting (stored in the display_mode variable). However I'm not too familiar with the various VIDC control registers and how different modes work under the hood, so I'm unsure of the correct behaviour here.

It will be exciting to see a Retroarch core of Arculator Acorn Archimedes Emulator Added to Future Updates of Retroarch if you're interested

For A3000 or 'lesser' models, selecting a CPU type causes the box to embiggen and stay that way until the window is closed.

Repeated with Arculator 2.2 on Windows 10.

Create a new machine and select RISC OS 3.00 ROM.
Extension ROM is enabled and HostFS appears on the iconbar.
But clicking on it just locks up the machine.
HostFS should be fixed to work on 3.00 or possibly really just disabled as it is when selecting RISC OS 2.

Is it possible for Arculator to start the emulator immediately and bypass the widgets config menu? (Either by specifying the machine via command line parameters or just have it read from a config file). If not is this something that can be added?

I would like to use Arculator as the backend for a bot like bbcmicrobot but currently it boots into a GUI options window which makes this tricky without some hacking.

ArcEm does start the emulator immediately but I'd rather use Arculator if I can

cc @myelin

I compiled Arculator v2.1 under Xubuntu 18.04.

When selecting a podule, the configure buttons remain greyed out, and when closing and reopening the
machine configuration window, the podule selection boxes returns to none.

Got Failed to open SO errors, when launching Arculator.

Here is a log:
[00000000]: Looking for podules in ./podules/ [00000000]: podule_probe returned 0x7f7065d6ad60 [00000000]: podule_probe returned 0x7f7065b64d60 [00000000]: Failed to open SO . ./podules/./..so: cannot open shared object file: No such file or directory [00000000]: Failed to open SO common ./podules/common/common.so: cannot open shared object file: No such file or directory [00000000]: podule_probe returned 0x7f706595ed60 [00000000]: podule_probe returned 0x7f7065758d60 [00000000]: Failed to open SO .. ./podules/../...so: cannot open shared object file: No such file or directory [00000000]: podule_probe returned 0x7f7065531d20 [00000000]: Failed to open SO pccard ./podules/pccard/pccard.so: cannot open shared object file: No such file or directory HDA ATI SB: PCM device=0:0:0 [00000000]: podule_probe returned 0x7f706531bd40 [00000000]: podule_probe returned 0x7f70650efd20 [00000000]: podule_probe returned 0x7f7064ec8d60 [00000000]: podule_probe returned 0x7f7064cbfd80 [00000000]: Loading ROM set 0 from ./roms/arthur030 [00000000]: Found ROM030 [00000000]: Loading ROM set 1 from ./roms/arthur120 [00000000]: Found ROM120 [00000000]: Loading ROM set 2 from ./roms/riscos200 [00000000]: Found ROM200 [00000000]: Loading ROM set 3 from ./roms/riscos201 [00000000]: Found ROM201 [00000000]: Loading ROM set 4 from ./roms/riscos300 [00000000]: Found ROM300 [00000000]: Loading ROM set 5 from ./roms/riscos310 [00000000]: Found ROM310 [00000000]: Loading ROM set 6 from ./roms/riscos311 [00000000]: Found ros311 [00000000]: Loading ROM set 7 from ./roms/riscos319 [00000000]: Found ROM319 [00000000]: Loading ROM set 8 from ./roms/arthur120_a500 [00000000]: Found A500_Arthur_ROM.rom [00000000]: Loading ROM set 9 from ./roms/riscos200_a500 [00000000]: Found ROM200.A500Build [00000000]: Loading ROM set 10 from ./roms/riscos310_a500 [00000000]: Found a500_riscos310

While compiling the current HEAD (17b63fd) on Linux, I receive an error while compiling wx-podule-config.cc (I've redacted the email address that showed up in the compile command):

make[1]: Entering directory '/opt/sophie/arculator-git/prog/src'
g++ -DPACKAGE_NAME=\"Arculator\" -DPACKAGE_TARNAME=\"arculator\" -DPACKAGE_VERSION=\"v2.0\" -DPACKAGE_STRING=\"Arculator\ v2.0\" -DPACKAGE_BUGREPORT=\"Sarah\ Walker\ \<email@redacted\>\" -DPACKAGE_URL=\"\" -DPACKAGE=\"arculator\" -DVERSION=\"v2.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_LIBZ=1 -DHAVE_LIBPTHREAD=1 -DHAVE_LIBOPENAL=1 -DHAVE_LIBASOUND=1 -I.    -I/usr/lib64/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -I/usr/include/SDL2 -D_REENTRANT -Wall -O0 -g -D_DEBUG -DDEBUG_LOG -MT arculator-wx-podule-config.o -MD -MP -MF .deps/arculator-wx-podule-config.Tpo -c -o arculator-wx-podule-config.o `test -f 'wx-podule-config.cc' || echo './'`wx-podule-config.cc
wx-podule-config.cc: In member function ‘void PoduleConfigDialog::OnCombo(wxCommandEvent&)’:
wx-podule-config.cc:351:77: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  351 |                                         update = item->function(this, item, (void *)(dynamic_cast<wxComboBox *>(obj)->GetCurrentSelection()));
      |                                                                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
wx-podule-config.cc: In function ‘void* podule_config_get_current(void*, int)’:
wx-podule-config.cc:588:32: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  588 |                         return (void *)cbox->GetSelection();
      |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
wx-podule-config.cc: In function ‘void podule_config_set_current(void*, int, void*)’:
wx-podule-config.cc:619:44: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
  619 |                         cbox->SetSelection((int)val);
      |                                            ^~~~~~~~
make[1]: *** [Makefile:1571: arculator-wx-podule-config.o] Error 1
make[1]: Leaving directory '/opt/sophie/arculator-git/prog/src'
make: *** [Makefile:400: all-recursive] Error 1

I was able to track the error down to commit 2cbbbe4; I was able to compile its parent commit (bb21e9e) successfully.

Relevant information:

• Distro: Gentoo (but a manual compile, not any kind of ebuild; I am using my own script to make sure I keep my data, though)
• Compile method: autoreconf -is && ./configure --enable-debug && make -j13 (but the error also occurs when using --enable-release-build with configure instead of --enable-debug)
• GCC version: 10.3.0 (but also occurs with 9.4.0, 8.4.0 and 6.5.0)
• autoconf version: 2.69

Hi.
Really appreciate the work to bring us the updated versions. Just wondering if it is possible to make it a bit more front end friendly :)
As the title suggests going straight to fullscreen at start would be nice and having a full exit to quit the emulator. Command line I guess would be the ideal. However I have no idea myself...
Also in 0.99 you could fullscreen by alt+v then f but it's not possible now. Could that be implemented again perhaps?

Thanks for your time

Trying to compile on Manjaro and I'm getting this error:

libtool: Version mismatch error. This is libtool 2.4.6 Debian-2.4.6-2, but the
libtool: definition of this LT_INIT comes from libtool 2.4.7.4-1ec8f-dirty.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6 Debian-2.4.6-2
libtool: and run autoconf again.

I've no idea how to follow the instruction ;-(

I recently bought a GreaseWeazle to archive my old Acorn floppies, and was quite excited to find my original Zelanites disk. This is apparently unobtainium from online software archives, probably due to the copy protection and MicroPower withdrawing from the game market the same year. It seems it was once included in the MESS Software List collection, but presumably dropped because it didn't work when run from a sector based floppy image.

I haven't been able to run this game since I upgraded my A3000 to RISC OS 3, so I didn't expect it to work with RISC OS 3 ROMs under emulation, which it, of course, doesn't. Unfortunately, when using a HFE floppy image it doesn't run with Arculator using RISC OS 2 either. The presents the loading screen, then aborts with a message saying it wasn't able to free enough memory, not matter how much is allocated. The code itself appears to be non-relocatable, so I guess it is trying to use a memory location which is available on real hardware, but not under the emulator..?

I have got it working under MESS (mostly ok), using the MFI floppy format. The MAME HFE loader doesn't want to read it so I haven't been able to compare running the same image on both emulators. If I use ADF with MESS it drops to the supervisor prompt after the loading screen, which is what I remember happening back in the day when I tried to back it up. Arculator fails with the same error regardless of the floppy image format.

Any thoughts?

Hello,

An interesting Arculator bug was found recently on one of my Stardot forum threads. It appears that *Unplug'ing the FPEmulator module on a RISC OS 3.11 machine with an FPA10 inside and then rebooting has different effects on Arculator vs. real hardware:

• On Arculator, the desktop will load successfully.
• On real hardware, the desktop fails to load with an "undefined instruction" error at &03877AC8, which is an RFS instruction.

The real hardware behaviour can be replicated on Arculator by disabling FPA10 emulation, which suggests that the FPA10 emulation is providing the RFS instruction when the real FPA10 does not.

I don't know what other instructions this might apply to, so I don't feel comfortable trying to fix this myself as I don't have real hardware to test it, unfortunately.

I was writing a Gentoo ebuild for Arculator and I realised it wasn't going to work because it expects to find its resources in the same directory as the executable. Is there a plan to implement loading/saving from standard system/user locations? (Like PCem does)

I ask because I previously implemented the XDG base directory specification for rpcemu, but the patch was not accepted and I don't want to waste my time with that again.

I'm using commit a4a3b63 on Gentoo Linux, with gcc 11.3.1.

When using the aeh50 podule on a machine, closing the machine window results in Arculator crashing and free(): invalid pointer being printed to the console.

The error seems to occur when ne2000_close() frees the ne2000 pointer (podules/common/net/ne2000.c:1449). ne2000 does point to an address, so this isn't a null pointer issue. That said, most of its members are 0 values, with others that don't seem to make sense. (For example, ne2000->ISR.pkt_rx is a negative value, which I assume is meant to be impossible.)

For example, here's how the first two members (ne2000->CR and ne2000->ISR) look at the time of one such crash:

I'm not entirely sure yet why this is occurring, but is it at all possible that the aeh50->ne2000 pointer is already getting freed somewhere else? Or otherwise overwritten with a pointer to somewhere else?

Note that this only applies to the aeh50 podule. The aeh54 podule doesn't crash or show any error.

2.2, under Windows 10, Choose "Disc - Disc Drive Noise - Disabled". Restart arculator or hard-reset the emulated machine and you get white noise on startup. Clicking a drive icon in RISC OS also gets white noise. Fully repeatable.

Create an A5000 model, one floppy drive as standard, start it and hear the drive-seeking noise four times, because A5000 probes all four possible drive selects. But only one floppy icon appears on the bar.
Drive noises should only be generated for drives which are configured as present hardware. A drive that doesn't exist can't make a noise.

The Linux build of Arculator 2.1 has a couple of case errors when packaging its ROMs, causing Linux to miss the ROM as filenames are, by default, case-sensitive:

• roms/podules/zidefs/ZIDEFSROM should be named roms/podules/zidefs/zidefsrom,
• roms/podules/zidefs_a3k/ZIDEFSROM should be named roms/podules/zidefs_a3k/zidefsrom.

In addition, the roms/podules/zidefs_a3k/roms.txt file has the upper-case name in it, which should be lower-case. A pull request for this change is coming shortly!

The SDL sound system isn't getting initialised for some reason. Reverting the removal of OpenAL support makes it work again.

When trying to compile the latest commit under Linux, the linking phase fails with many "multiple definition of" errors. Here's the first, along with the command that triggered it and the output before the error:

/bin/sh ../../../libtool  --tag=CC   --mode=link gcc -I../../../src -Wall -O0 -g -D_DEBUG -DDEBUG_LOG   -o libpccard.la -rpath /usr/local/lib libpccard_la-pccard_podule.lo pcem/libpccard_la-808x.lo pcem/libpccard_la-386.lo pcem/libpccard_la-386_common.lo pcem/libpccard_la-386_dynarec.lo pcem/libpccard_la-cpu.lo pcem/libpccard_la-cpu_tables.lo pcem/libpccard_la-diva.lo pcem/libpccard_la-dma.lo pcem/libpccard_la-io.lo pcem/libpccard_la-lpt.lo pcem/libpccard_la-mem.lo pcem/libpccard_la-pc.lo pcem/libpccard_la-pic.lo pcem/libpccard_la-pit.lo pcem/libpccard_la-scamp.lo pcem/libpccard_la-serial.lo pcem/libpccard_la-timer.lo pcem/libpccard_la-x86seg.lo pcem/libpccard_la-x87.lo pcem/libpccard_la-x87_timings.lo libco/libpccard_la-libco.lo -lasound -lopenal -lpthread -lz  -L/usr/lib64 -pthread   -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0  -lSDL2  -lasound -lopenal -lpthread -lz  -L/usr/lib64 -pthread   -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0  -lSDL2 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libpccard_la-pccard_podule.o pcem/.libs/libpccard_la-808x.o pcem/.libs/libpccard_la-386.o pcem/.libs/libpccard_la-386_common.o pcem/.libs/libpccard_la-386_dynarec.o pcem/.libs/libpccard_la-cpu.o pcem/.libs/libpccard_la-cpu_tables.o pcem/.libs/libpccard_la-diva.o pcem/.libs/libpccard_la-dma.o pcem/.libs/libpccard_la-io.o pcem/.libs/libpccard_la-lpt.o pcem/.libs/libpccard_la-mem.o pcem/.libs/libpccard_la-pc.o pcem/.libs/libpccard_la-pic.o pcem/.libs/libpccard_la-pit.o pcem/.libs/libpccard_la-scamp.o pcem/.libs/libpccard_la-serial.o pcem/.libs/libpccard_la-timer.o pcem/.libs/libpccard_la-x86seg.o pcem/.libs/libpccard_la-x87.o pcem/.libs/libpccard_la-x87_timings.o libco/.libs/libpccard_la-libco.o   -L/usr/lib64 -lasound -lopenal -lpthread -lz -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lSDL2  -O0 -g -pthread -pthread   -pthread -Wl,-soname -Wl,libpccard.so.0 -o .libs/libpccard.so.0.0.0
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: pcem/.libs/libpccard_la-386.o:/opt/sophie/arculator-git/prog/podules/pccard/src/pcem/ibm.h:27: multiple definition of `ram'; pcem/.libs/libpccard_la-808x.o:/opt/sophie/arculator-git/prog/podules/pccard/src/pcem/ibm.h:27: first defined here

There are 453 of these errors in total, and after some debugging it appears these issues have existed ever since the PC card was first available to Linux users in ddbbf0b, but they didn't show up before now because the Makefile wasn't generated (which was fixed in cea295f). Additionally, the errors that 8e11b5f fixed was masking these errors.

Full build log using gcc 11.2.1: pccard-build-log.txt