Jupiter Ace emulator

discuss both original and modern hardware for the bbc micro/electron
RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Jupiter Ace emulator

Post by RobC » Sat Dec 09, 2017 4:39 pm

At ABUG, Rich/revaldinho suggested that, after completing my ZX81 emulator, I could develop a Jupiter Ace emulator too as it's a fairly similar machine and is interesting because it came with Forth rather than BASIC.

So, here's a Jupiter Ace emulator for the native Pi Co-pro on the Beeb. I've never used an Ace before but got lots of information from the Jupiter Ace Resource Archive:
https://www.jupiter-ace.co.uk/

The core is based on Xace:https://github.com/lawrencewoodman/xAce

It supports .tap files for loading and saving and works with most of the games I've tried. Sound emulation is a bit hit and miss as I'm using the Beeb's SOUND command rather than programming the sound chip directly.

You'll need the latest Diamondback RC2 release to get it to work. To run it, put the Pi co-pro into native ARM mode with *FX 151,230,15 and then do:
*BAce [tapfilename]

If you specify a tapfilename on the command line, the .tap file will be attached on start-up. Otherwise, you can attach a file within the emulator by doing F4 and choosing a file.

For full instructions do *TYPE README. I've included some games - each game seems to have it's own loading command so it's worth reading the instructions!

EDIT: Latest version now in the post below.
Last edited by RobC on Sun Dec 10, 2017 12:46 pm, edited 1 time in total.

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sat Dec 09, 2017 6:18 pm

Thanks for this! I've just tried it, but can't get it to work properly. Not sure if it's something I'm doing (or not doing).

If I do a *BAce Meteors, I get a Bad String message.

If I do a *BAce without any filenames I get a blank screen. If I press F4 I can get the ability to enter a filename. If I enter Meteors, I'm then back to a blank screen. Sometimes I'll come back to a screen with a bunch of OK's. The only keys that seem to do anything are F1, F2, F3 and Esc.

This is on a PiCoPro with Diamandback RC2. It works fine with the ZX81 emulator.

Edit: Key presses do seem to work, but the screen doesn't refresh, so I can't see what I've typed. If I press F3 and then press a key to go back, the key presses I typed earlier appear.
Last edited by KenLowe on Sat Dec 09, 2017 6:32 pm, edited 1 time in total.

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sat Dec 09, 2017 6:29 pm

Ken,

What filesystem are you using?

Dave

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sat Dec 09, 2017 6:33 pm

I'm using SWMMFS. I've also just edited my initial post with some more info.

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sat Dec 09, 2017 6:41 pm

I'm also getting the same "Bad String" error.

Possibly relating to this issue?
https://github.com/hoglet67/PiTubeDirect/issues/35

Dave

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sat Dec 09, 2017 6:48 pm

I can get meteors running with:

Code: Select all

*BACE
F4 METEORS
l asteroids g
(the l asteroids g is in the README)

It's fast, mind you!

Dave

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sat Dec 09, 2017 6:56 pm

For some reason I just can't see anything I type (other than the Fx commands).

After doing the F4 METEORS.

If I blindly type (occasionally pressing F3 and then anykey, to see what I've actually typed):

load asteroids g

it does load the file, but the screen just doesn't refresh. Again, if I press F3 and then any key, I can see a snapshot of the game on screen. It makes it kinda difficult to play!!!

Edit: This BBC does have a shadow ram board (IntegraB) installed. Not sure if that might be having an impact? I've also disabled all non critical ROMs on this board.
Last edited by KenLowe on Sat Dec 09, 2017 7:13 pm, edited 1 time in total.

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sat Dec 09, 2017 7:13 pm

KenLowe wrote: it does load the file, but the screen just doesn't refresh. Again, if I press F3 and then any key, I can see a snapshot of the game on screen. It makes it kinda difficult to play!!!
Hmm, I don't see this. The screen is continually refreshed. As I type "load asteroids g" I see each key press echoed.

Dave

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sat Dec 09, 2017 7:15 pm

Duh. Again, I've done an edit just as you've posted!

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sat Dec 09, 2017 7:21 pm

Rob,

Any chance you could share the sources for this emulator?

It would be good to see:
- how command line args are parsed
- how screen updated are done

Dave

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sat Dec 09, 2017 8:00 pm

Sorry for the late reply but I've been out.

Ken: What happens if you just do *BAce (i.e. without any arguments)? Do you see the cursor/prompt and are you able to enter commands?

All the screen updates are done by VDU streams that move the text cursor to the correct location and then print the bytes that have changed (i.e. VDU 31, x, y, b1, b2, b3 etc.).

I'll post the source once I've put the kids to bed...

EDIT: On the Bad String thing, I've not seen this but I'm using an ADFS hard drive image under GoSDC - I'll try using DFS to see if that shows up anything.

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sat Dec 09, 2017 8:04 pm

RobC wrote:Ken: What happens if you just do *BAce (i.e. without any arguments)? Do you see the cursor/prompt and are you able to enter commands?
I don't get any prompt. I just get a blank screen. I am able to enter commands, I just can't see what I'm typing on screen (unless I press F3 and then any key to get back to the screen, which is then refreshed and shows what I typed).

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sat Dec 09, 2017 8:25 pm

That's weird. The screen refresh function should be called at regular intervals once the character RAM has been written to by the Z80.

It's also called after a memory dump (F3) to restore the display so this shows that it does work with your setup and would imply that isn't being called when it should be.

One thing I've just remembered is that I'm using my own build of PiTubeDirect rather than the official Diamondback RC2. I'll put this on my machine to see if the problems then turn up.

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sat Dec 09, 2017 8:35 pm

RobC wrote: One thing I've just remembered is that I'm using my own build of PiTubeDirect rather than the official Diamondback RC2. I'll put this on my machine to see if the problems then turn up.
I'm using Diamondback RC2 on a Model B with MMFS and not having any update issues.

I do get the Bad String error, which I expect is a bug in the PiTubeDirect command line args processing.

Dave

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sat Dec 09, 2017 8:46 pm

Cheers Dave. Presumably, you see "Bad string" when you do: BAce filename?

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sat Dec 09, 2017 9:01 pm

I've just tried this on another machine with a different RPi, and MMFS instead of SWMMFS, and the screen refresh is working ok. I'll try and narrow it down a bit.

Edit: So, I've just checked, and it's a PiZeroW in both machines, both with Diamondback RC2, and both running at 700MHz. And without doing anything else, it's now working on both machines. Don't know what I've done!
Last edited by KenLowe on Sat Dec 09, 2017 9:16 pm, edited 1 time in total.

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sat Dec 09, 2017 9:05 pm

RobC wrote:Cheers Dave. Presumably, you see "Bad string" when you do: BAce filename?
Yes. How do you parse the command line params?

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sat Dec 09, 2017 9:07 pm

Ken: I do have Dave/Arcadian's old *broken* IntegraB board here. I've not looked at it yet but I could try to get it working to see if I get the same issues...
hoglet wrote:Yes. How do you parse the command line params?
I'm using some code from Sprow's ARMTDMI C coding example. It copies the command line out of the I/O processor then parses the arguments. It works perfectly on my machine (model B, VideoNuLA and GoSDC using ADFS).

I'll put the source in a zip file and post it in a few minutes...

EDIT: Source code added.
Attachments
BAce_src.zip
(48.34 KiB) Downloaded 23 times
Last edited by RobC on Sat Dec 09, 2017 9:18 pm, edited 1 time in total.

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sat Dec 09, 2017 9:18 pm

RobC wrote:Ken: I do have Dave/Arcadian's old *broken* IntegraB board here. I've not looked at it yet but I could try to get it working to see if I get the same issues...
I've just checked my systems, and it's a PiZeroW in both machines, both with Diamondback RC2, and both running at 700MHz. And without doing anything else, it's now working on both machines. Don't know what I've done!

User avatar
jgharston
Posts: 3930
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Jupiter Ace emulator

Post by jgharston » Sat Dec 09, 2017 11:12 pm

RobC wrote:
hoglet wrote:Yes. How do you parse the command line params?
I'm using some code from Sprow's ARMTDMI C coding example. It copies the command line out of the I/O processor then parses the arguments. It works perfectly on my machine (model B, VideoNuLA and GoSDC using ADFS).
You shoudn't need to do that, OS_GetEnv returns pointing to a local copy of the command line, you should just use that, that's what it's for.

Code: Select all

    // Get application space limit and command line
    swi     OS_GetEnv
    // R0=>command line, R1=environment limit
    // Environment RAM limit becomes stack base (rounded down to nearest 8)
    bic     r13, r1, #7    
    // call application entry
    bl __appentry
...later....
int __appentry()
{
  /* this is entered with R0=>command line

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sun Dec 10, 2017 8:18 am

jgharston wrote:You shoudn't need to do that, OS_GetEnv returns pointing to a local copy of the command line, you should just use that, that's what it's for.
Yes - I'd seen that but, as the original code was working on my ARMTDMI PDP-11 emulator, I just left it in.

I can change the code but I'm not seeing the "Bad string" error. One thing that I did want to check was whether the ZX81 emulator has the same issue. If not, I can narrow it down as the code is very similar...

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sun Dec 10, 2017 8:48 am

This is the code being used to obtain the command line:

Code: Select all

    // Read the command-line address from the io processor
    errptr = _swix(OS_Args, _INR(0,2)|_OUT(2), 1, 0, 0, &ioAddress);
    // We want all of the command-line so back up to the
    // nearest page (0x700 on B and B+ and 0xDC00 on a master)
    ioAddress = (ioAddress / 256) * 256;
    // copy the memory over from the io processor to the ARM
    memcpyfromio_slow(commandline, (void*)ioAddress, sizeof(commandline));
Can anyone point me at where using OSARGS to read the command line is documented?

It's not obvious from here:
http://beebwiki.mdfs.net/OSARGS

What value does _INR(0,2)|_OUT(2) result in?

Code: Select all

#define _INR(i,j)  (~0 << (i) ^ ~0 << ((j) + 1))
#define _OUT(i)    ((i) != _FLAGS? (1U << (31 - (i))): 1U << 21)
Are you using a Master or a Model B?

I wonder if this is ADFS specific?

Dave

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sun Dec 10, 2017 10:30 am

hoglet wrote: Can anyone point me at where using OSARGS to read the command line is documented?
I've been using the Beeb AUG just to ensure there's no confusion with any RISC OS differences. OSARGS is on P.337.
hoglet wrote:What value does _INR(0,2)|_OUT(2) result in?
It's a way of indicating the nature of the parameters of the SWI call following the SWI number. In the call, if required, inputs are specified first (in register order), then outputs, then flags. (I didn't come up with this - it's all taken from Sprow's ARMTDMI code. However, I believe it's one of the usual ways things are done in C on RISC OS - I certainly had come across it before, probably when writing C using the Norcroft compiler on a RiscPC.)

For a Beeb-related call (with accumulator, x register and y register), you might do something like:

_swi(swi_no, _IN(0)|_IN(1)|_IN(2)|_OUT(0)|_OUT(1)|_OUT(2)|_OUT(_FLAGS), a, x, y, &out_a, &out_x, &out_y, &flags);

_INR and _OUTR are just convenient ways of specifying ranges.

So, _INR(0,2) indicates that r0, r1 and r2 are to be set from the next three parameters and _OUT(2) indicates that the value of r2 should be stored in the next variable after that (hence it being given as a pointer).
hoglet wrote:Are you using a Master or a Model B? I wonder if this is ADFS specific?
I'm using a model B with GoSDC emulating an ADFS hard drive. I'll try various other filing systems/machines later today.

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sun Dec 10, 2017 10:38 am

My guess is this is an MMFS bug with OSARGS. I'll try to confirm that later.

Dave

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sun Dec 10, 2017 10:49 am

hoglet wrote:My guess is this is an MMFS bug with OSARGS. I'll try to confirm that later.

Dave
I also get the same error with RetroClinc RamFS.

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sun Dec 10, 2017 11:05 am

Given that files open correctly when 'F4' is used instead, I wonder whether the issue is with OSFIND needing a carriage-return terminated string?

The F4 usage will call OS_ReadLine/OSWORD 0 and get a correctly terminated string. I'm wondering whether OSARGS on the GoSDC also does this but other filing systems don't?

I'll do some investigation on my DataCentre...

User avatar
KenLowe
Posts: 1112
Joined: Mon Oct 18, 2004 5:35 pm
Location: Scotland
Contact:

Re: Jupiter Ace emulator

Post by KenLowe » Sun Dec 10, 2017 11:12 am

RobC wrote:The F4 usage will call OS_ReadLine/OSWORD 0 and get a correctly terminated string. I'm wondering whether OSARGS on the GoSDC also does this but other filing systems don't?
I've just tried on GoSDC with patched DFS 2.26 and I still get the same error.

RobC
Posts: 2807
Joined: Sat Sep 01, 2007 10:41 pm
Contact:

Re: Jupiter Ace emulator

Post by RobC » Sun Dec 10, 2017 11:21 am

KenLowe wrote:I've just tried on GoSDC with patched DFS 2.26 and I still get the same error.
That helps - I've been using ADFS. I'll try DFS too...

EDIT: I'm seeing the same "Bad string" message under DFS on GoSDC but it's fine under ADFS. I'll investigate...

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sun Dec 10, 2017 11:53 am

It looks to be like it might be a bug in the command line args parsing in the Ace C code.

I'be been looking at what's sent over the tube (with the 6502 protocol analyzer, wooo!)

Here's the data received (one byte at a time using OSWORD) by memcpyfromio_slow

Code: Select all

42 41 43 45 20 4D 45 54 45 4F 52 0D 31 35 0D 00 BACE METEOR.15..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Here's the subsequent OSFILE request, which should look like: &12 A string &0D

Code: Select all

12 C0 4D 45 54 45 4F 52 00 31 35 0D             ..METEOR.15.
It looks like the filename part is: 4D 45 54 45 4F 52 00 31 35 0D, which is incorrect.

So it seems like the args parsing has somehow gone amiss:

Code: Select all

int __appentry()
{
  int flags = 0;
  _kernel_oserror *errptr;
    char *args;
    char commandline[128];
    UINT32 ioAddress;
    UINT32 maxmem;
    long long starttime = 0;

    // Read the command-line address from the io processor
    //    _swi(OS_Args, _INR(0,2)|_OUT(2), 1, 0, 0, &ioAddress);
    errptr = _swix(OS_Args, _INR(0,2)|_OUT(2), 1, 0, 0, &ioAddress);
    // We want all of the command-line so back up to the
    // nearest page (0x700 on B and B+ and 0xDC00 on a master)
    ioAddress = (ioAddress / 256) * 256;
    // copy the memory over from the io processor to the ARM
    memcpyfromio_slow(commandline, (void*)ioAddress, sizeof(commandline));

    args = commandline;
    int nchar = 0;
    int narg = 1;
    argvec[0] = args;

    while (args[nchar] != 0 && args[nchar] != '\r' && args[nchar] != '\n' && nchar < 128)
    {
        if (args[nchar] == ' ')
        {
            args[nchar++] = '\0';
            argvec[narg++] = &args[nchar];
        }
        else
        {
            nchar++;
        }

        // Too many arguments, so we'll stop there
        if (narg > (sizeof(argvec) / sizeof(char*)))
        {
            break; // out of the while
        }
    }
    args[nchar] = '\0';

    return main(narg, argvec);
}
But I can't quite see where!

Dave
Last edited by hoglet on Sun Dec 10, 2017 12:16 pm, edited 1 time in total.

User avatar
hoglet
Posts: 9091
Joined: Sat Oct 13, 2012 7:21 pm
Location: Bristol
Contact:

Re: Jupiter Ace emulator

Post by hoglet » Sun Dec 10, 2017 11:57 am

I'm thinking now that the bug is that the args parsing is leaving an <00> terminated string and the subsequent fopen (OSFIND) is expecting an <0d> terminated string.

What I'm not sure about is what the OS_Find API actually specifies:
https://www.riscosopen.org/wiki/documen ... ow/OS_Find

I wonder if PiTubeDirect's implementation of the OS_Find API should interpret any control character as the filename terminator?
Last edited by hoglet on Sun Dec 10, 2017 12:21 pm, edited 5 times in total.

Post Reply

Return to “8-bit acorn hardware”