Arculator v2.0 released!

[pdjstone]

I discovered an incompatibility between hostfs in Arculator 0.99 vs 2.0. The previous version would strip extensions from filenames - so hello.txt would appear as "hello" inside the emulator. The current version keeps the extension and replaces dot with slash (e.g. hello/txt). This caused problems for me with my hostfs filesystem which I had originally copied from Red Squirrel (an older Acorn emulator) and had a lot of files with .dat extensions. Also the default filetype has changed from data (ffd) to text (fff).

[pdjstone]

I've put up a GitHub repo with my fixes to the Arculator 2.0 code at https://github.com/pdjstone/arculator. The current changes are:

- Fix for startup crash
- Fixed disc noise menu options not working (some other volume options still don't work)
- Added some extra keyboard shortcuts - ctrl-insert to release the mouse and ctrl-enter to go fullscreen
- Strip filename extensions in hostfs

There's a few more changes I hope to make soon - see the GitHub issues for more details.

[jms2]

I have just installed version 2 of Arculator and I'm very impressed! Thanks Sarah.

However I do seem to have slightly broken it while trying to get a hard disc set up. I managed to get the HD working, but in the process I have lost HostFS/ArculFS. I don't know how I did it... and I don't seem to be able to switch it back on!

[arthurseat]

Thank you so much, it's amazing

I was despairing with ArcEm, not working at all, so I was really happy to find Arculator.
Getting a hard disk image installed was not documented but I found the info elsewhere so now I can access my old A310 files.

Thank you!

[akumpu]

Hi everyone

Which is the right place to report bugs and possible corrections?
GitHub or this forum?

br.ari

[SarahWalker]

This forum.

[akumpu]

The issue is visible when using for example, when used: A3020 emulation with 2MB RAM setting
With these settings the code does memory buffer overflow and sometimes it triggers a segmentation fault

The problem is caused by "resetpagesize" function, which is called when MEMC control register is updated
In this case 'mempoint' array gets pointer values which goes beyond allocated RAM space.

From me "resetpagesize" is not needed at all. Because you're
re-initializing target's memory map which belongs to its physical RAM area
which should be always same, i.e. RAM space repeated N times. The used page size shouldn't affect to it, right?

So it should be enough that it is initialized only at startup.

But what is mentioned in the datasheet is:
"- The address translator mappings are not affected by reset, but are effectively scrambled if the page size is changed."

So if we want better emulation, we should scramble 0...1FFF from 'mempoint' array.
But what "scrambled" means, is then a good question

And then some minor findings:
From resizemem, line 132 is useless:
" for (c=0;c<0x4000;c++) mempointb[c]=(uint8_t *)mempoint[c];"
RAM area is already initialized (0x2000...0x3000), and others (0x0...0x1fff) will be
initialized when the pages are configured.

And GCC is giving a warning:
fdi2raw.c:1675:25: warning: integer overflow in expression of type ‘int’ results in ‘2147483645’ [-Woverflow]
1675 | if (randval <= (3 * RAND_MAX / )

I don’t know what a mess that could cause, to be honest

[SarahWalker]

The issue is visible when using for example, when used: A3020 emulation with 2MB RAM setting
With these settings the code does memory buffer overflow and sometimes it triggers a segmentation fault

The problem is caused by "resetpagesize" function, which is called when MEMC control register is updated
In this case 'mempoint' array gets pointer values which goes beyond allocated RAM space.

Yes, I see it. Looks like the masks are a little off. Easily corrected!

From me "resetpagesize" is not needed at all. Because you're
re-initializing target's memory map which belongs to its physical RAM area
which should be always same, i.e. RAM space repeated N times. The used page size shouldn't affect to it, right?

Nope. MEMC uses the configured page size to determine DRAM size, which means that if it's misconfigured you'll get bad decoding and mirrored areas in the physical RAM area. RISC OS uses this to determine memory size, if you present physical RAM as you've suggested then it will always use a 32k page size.

But what is mentioned in the datasheet is:
"- The address translator mappings are not affected by reset, but are effectively scrambled if the page size is changed."

This basically means that the mappings are interpreted differently with different page size settings (as the physical address -> DRAM column/row mapping changes). For full accuracy Arculator should regenerate mempoint when the page size is changed, however as page size is only changed when detecting and configuring memory size, at which point there are no logical mappings, this doesn't really have any effect.

[SarahWalker]

Since BitBucket are dropping Mercurial support I've moved Arculator onto Git. And off BitBucket. The main repo is now at https://github.com/sarah-walker-pcem/arculator.

[davidb]

Are you going to create a repository for Elkulator there, too?

[SarahWalker]

Probably not, as I don't intend to do any more work on Elkulator.

[daveejhitchins]

Probably not, as I don't intend to do any more work on Elkulator.

Dave H

[Kazzie]

I've had a got at building Arculator for Linux (Arch, x86_64), but have gotten stuck with a compilation error. After running ./configure --enable-release-build and make, I get the following error when make is linking:

/usr/bin/ld: arculator-cp15.o:(.bss+0x10): multiple definition of `arm3cp'; arculator-arm.o:(.bss+0x1a0): first defined here
/usr/bin/ld: arculator-mem.o:(.bss+0x90080): multiple definition of `arm3cp'; arculator-arm.o:(.bss+0x1a0): first defined here
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:545: arculator] Error 1

The same error occurs with the source from http://b-em.bbcmicro.com/arculator/download.html and also the two git repositories mentioned upthread.

I can't think what would be causing compilation to fail on my machine, when others in this thread have successfully build it on Linux.

Any suggestions?

[z9k9]

Hi Kazzie - I'm also using Linux (Arch, x86_64) and had the same linker errors as you. I fixed it as follows:


In src/cp15.h, replace

Code: Select all

    struct
    {
            uint32_t ctrl;
            uint32_t cache,update,disrupt;
    } arm3cp;

with

Code: Select all

    extern struct arm3cp_t
    {
            uint32_t ctrl;
            uint32_t cache,update,disrupt;
    } arm3cp;

And in src/cp15.c, add

Code: Select all

    struct arm3cp_t arm3cp;

at line 10 (ie. after the line: "int cp15_cacheon;").


This applies to both git repositories above though ultimately I had to use pdjstone's one, to also avoid the startup crash he describes fixing in this post.

[z9k9]

Oh I forgot, there was one other thing, here on Arch Linux.

At the very start before ./configure I had to run "autoreconf -fi". Else I got:

From Sarah's repo, during ./configure:

Code: Select all

     configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

From pdjstone's repo, after the final link:

Code: Select all

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

My installed version of autoconf is 2.69, and libtool is 2.4.6.42. I don't much understand these tools, so that autoreconf command I googled up might be a rather blunt way of dealing with this, possibly.

[Kazzie]

Hi Kazzie - I'm also using Linux (Arch, x86_64) and had the same linker errors as you. I fixed it as follows:

Thanks for the guidance z9k9, I should get a chance to try it over the weekend.

I suspect I also used 'autoreconf' in my early attempts to get things compiled; it rings a bell.

[jms2]

Having watched Paul Fellowes' excellent ABUG talk, I thought I would have a play with it using Arculator v2. I can get Arthur 0.3 running, but I don't seem to be having any success with Arthur 1.2. I have found two images online:

- The one on 4corn and Eelco Huinunga's site is a single file which is one byte over 512k (an extra &5C on the end, after a lot of &FFs). This one boots as far as showing the banner, but then hangs with a non-flashing cursor. I tried chopping the extra byte off, but this didn't help.

- There's also one on Domesday86.com which is from an A500. This one is only 256k long, but it isn't simply the 512k version cut in half because it ends halfway through the credits, which are in a totally different place to the other image.

I'm assuming that I must be doing something wrong with these images, as Arculator runs everything else perfectly, and other people report getting Arthur to work. All I have done is drop them into the relevant "roms" folder (unzipped of course).

[SarahWalker]

You need to remove the "Arculator support modules" podule; this appears to cause Arthur to hang.

I would expect issues with the A500 image, as Arculator doesn't emulate A500 hardware. The 256k image does appear to boot to BASIC, but I couldn't get the associated hard drive image to mount. The hard drive will mount on regular Arthur 1.2 though.

[SarahWalker]

Okay, a quick skim through the A500 HW guide shows that there are a number of changes to floppy & hard drive interfacing between the A500 and the production machines, particularly around interrupts. Which would be why the A500 Arthur can't mount the hard drive. I've avoided emulating the A500 up til now because I wasn't aware of any ROM or disc images around for it, now that I'm aware of this one it might be a project for the weekend

[jms2]

Ok thanks for the advice - I never would have considered removing the support podule as I assumed it must be essential.

I’m not bothered about emulating the A500 personally, but if you do try please be aware that the rom does seem to be incomplete (although perhaps they are all like that ... and there’s nothing after the credits in a normal Arthur rom anyway)

[SarahWalker]

It's probably missing a number of modules that are loaded from disc. Arthur / RISC OS development ROMs are like that.

[steve3000]

It's probably missing a number of modules that are loaded from disc. Arthur / RISC OS development ROMs are like that.

It is, and that A500 is sitting on my desk at the moment (on loan from Xavier). I think the full HDD image is on doomsday86.com, it chugs away on boot up, loading the modules. Would be nice to have that emulated in Arculator as a curiosity if anything. It feels very much half way between a Beeb and an Archimedes...(although much heavier!)

[sirbod]

Sarah, if you're making changes, could you please update Arculator to support 4MB ROM's and post the binary so we can start making some progress on RISC OS 3.20 testing/development.

[SarahWalker]

Arculator's open source, if you want that kind of change do it yourself.

[IanJeffray]

Sarah, if you're making changes, could you please update Arculator to support 4MB ROM's and post the binary so we can start making some progress on RISC OS 3.20 testing/development.

Phil already did... https://github.com/philpem/arculator/co ... ee914ed91b

[AJW]

Thank you so much, it's amazing

I was despairing with ArcEm, not working at all, so I was really happy to find Arculator.
Getting a hard disk image installed was not documented but I found the info elsewhere so now I can access my old A310 files.

Thank you!

Do you mind sharing how?

[arakeen]

I put some steps that seem to work in another thread:

viewtopic.php?f=30&t=16314&p=287253#p287253

[jpagen]

Yes, that should work.

Been using Arculator for several years. Thanks for v2!

I wanted to create an image in Arculator which I could then use on my real A3000 (via a ZIDEFS and SD card to IDE interface )

After creating the image in Arculator v2 using the ZIDEFS IDE controller and writing the image to the SD card, the card cannot be read in the A3000 despite setting the applicable ZIDEFS configurations on the A3000.

Please can anyone help?

I have tried writing the image to the SD card using different imaging options including DD on Linux.

The furthest I have got was 'Quick' reformatting the SD card on Windows after writing the image to the SD card. I was then able to see the partitions & files on the real A3000. However re-imaging the the SD card and copying the files back to HOSTFS, showed a small number of files were corrupted in the process. I assume this was due to 'Quick' reformatting the SD card.

I have repeated this several times but get the same result each time. I am remembering to unmount the SD card after writing the image. Ideally I would like to copy files from HOSTFS to the SD card within Arculator but but don't think it is possible.


Thanks

[z9k9]

New insight on the linker errors I previously posted a fix for here.

It's due to a change in GCC 10:

GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking.

So another way to avoid the errors (aside from what was in my previous post) is to build with -fcommon:

Code: Select all

make CFLAGS=-fcommon

I got the tip off from here, which includes a bit more description about what this switch actually means.

[Andy1979]

Yes, that should work.

Been using Arculator for several years. Thanks for v2!

I wanted to create an image in Arculator which I could then use on my real A3000 (via a ZIDEFS and SD card to IDE interface )

After creating the image in Arculator v2 using the ZIDEFS IDE controller and writing the image to the SD card, the card cannot be read in the A3000 despite setting the applicable ZIDEFS configurations on the A3000.

Please can anyone help?

I have tried writing the image to the SD card using different imaging options including DD on Linux.

The furthest I have got was 'Quick' reformatting the SD card on Windows after writing the image to the SD card. I was then able to see the partitions & files on the real A3000. However re-imaging the the SD card and copying the files back to HOSTFS, showed a small number of files were corrupted in the process. I assume this was due to 'Quick' reformatting the SD card.

I have repeated this several times but get the same result each time. I am remembering to unmount the SD card after writing the image. Ideally I would like to copy files from HOSTFS to the SD card within Arculator but but don't think it is possible.


Thanks

Have you tried formatting the card in the A3000 first, taking an image of the formatted card and then using that in Arculator? Might stand a better chance of working when you copy back to the card that way. That’s what I’ve done with my A3010, though it uses a different interface. I have also found that a raspberry Pi running Risc OS 5 can mount my A3010 compact flash card natively in a USB card reader which is handy for bulk copying files to it.