MAME: How to ... ?

[SteveF]

Thanks Nigel, I can confirm ReCo6502 works for me. That's enough for me to test what I wanted to test anyway, cheers.

[Pernod]

Thanks Nigel, I can confirm ReCo6502 works for me. That's enough for me to test what I wanted to test anyway, cheers.

My post at viewtopic.php?f=4&t=14384&start=30#p202912 suggests the Acorn copros used to work. Will have to investigate this.

[daveejhitchins]

Thanks, that's helped but I'm still not quite there. I now get a Tube banner and the DFS name and BASIC, but I never get a BASIC prompt. If I press F12 (BREAK) I sometimes get a * prompt, sometimes with "Bad" on the previous line.

I'm sure I tried the Acorn 6502 last night and it worked, but now seeing same as you. Only the ReCo6502 (65C02) seems to be working.

As the Acorn copros were never intended for use with an Electron I can't be sure of expected behaviour. It would be useful to know which are known to work unmodified with original hardware.

I can add here that in reality EVERY CoPro that works on the BBC should work on the Electron - the only Caveat is that any associated software/firmware may not work!

The Electron Hardware and the Tube code is of Acorn's design.

Dave H.

[hoglet]

I can add here that in reality EVERY CoPro that works on the BBC should work on the Electron - the only Caveat is that any associated software/firmware may not work!

Just to expand on this slightly...

There is one crucial difference: the host side of the Tube is mapped to &FEEx on the Beeb, and &FCEx on the Electron.

Why does this difference matter? After all, surely this is handled by the tube code in the OS/DFS?

Well, on the Z80 Co Pro the client ROM actually contains 6502 code that is uploaded to the host (providing additional OSWORD calls). This code directly accesses the Tube registers. So the Z80 Co Pro client ROM needs patching to work on the Electron. (PiTubeDirect has a flag to allow this to be done).

And on the 80x86 Co Pro it's even worse, as both the Client ROM and DOS Plus embed host-side 6502 code. I've never managed to get this to work at all on the Electron.

All the other Co Pros (32016, ARM, 6809, PDP11) are well-behaved, so should work.

Dave

[daveejhitchins]

I can add here that in reality EVERY CoPro that works on the BBC should work on the Electron - the only Caveat is that any associated software/firmware may not work!

Just to expand on this slightly...

There is one crucial difference: the host side of the Tube is mapped to &FEEx on the Beeb, and &FCEx on the Electron.

Why does this difference matter? After all, surely this is handled by the tube code in the OS/DFS?

Well, on the Z80 Co Pro the client ROM actually contains 6502 code that is uploaded to the host (providing additional OSWORD calls). This code directly accesses the Tube registers. So the Z80 Co Pro client ROM needs patching to work on the Electron. (PiTubeDirect has a flag to allow this to be done).

And on the 80x86 Co Pro it's even worse, as both the Client ROM and DOS Plus embed host-side 6502 code. I've never managed to get this to work at all on the Electron.

All the other Co Pros (32016, ARM, 6809, PDP11) are well-behaved, so should work.

Dave

Thanks for that clarity, Dave . . .

Dave H.

[SteveF]

Is it possible to emulate an Electron with Plus 3 and sideways RAM? It feels like this is possible but my best efforts seem to fail e.g.:

Code: Select all

mame64 electron -exp romboxp -cart1 aqr -cart2 peg400 -window -rom1 ..\AP6v131-pad.rom

gives me 64K of sideways RAM, but:

Code: Select all

mame64 electron -exp romboxp -cart1 aqr -rom1 ..\AP6v131-pad.rom -exp plus3 -window

doesn't seem to give me any (and the ROM doesn't seem to be loaded). I've tried tweaking the ordering and using plus1 instead of romboxp but nothing seems to help. I'm sure this works, I just can't find the right way to tell MAME what I want...

[Pernod]

Is it possible to emulate an Electron with Plus 3 and sideways RAM? It feels like this is possible but my best efforts seem to fail e.g.:

Code: Select all

mame64 electron -exp romboxp -cart1 aqr -cart2 peg400 -window -rom1 ..\AP6v131-pad.rom

gives me 64K of sideways RAM, but:

Code: Select all

mame64 electron -exp romboxp -cart1 aqr -rom1 ..\AP6v131-pad.rom -exp plus3 -window

doesn't seem to give me any (and the ROM doesn't seem to be loaded). I've tried tweaking the ordering and using plus1 instead of romboxp but nothing seems to help. I'm sure this works, I just can't find the right way to tell MAME what I want...

Code: Select all

mame64 electron -exp plus3 -exp:plus3:exp romboxp -cart1 aqr -rom2 ..\AP6v131-pad.rom -window

Note that expansion devices are chained, so you need to specify that romboxp is attached to the plus3. The romboxp doesn't have a pass-through expansion port.

The Rombox+ can be configured (Machine Configuration in UI) to map ROMs to slots 4-7 or 12-15. The Plus3 puts ADFS into 4, and the Rombox+ puts it's Expansion ROM into 12, so load your AP6 into rom2 which will be either 5 or 13.

Sideways RAM will be much easier in the next release as it'll have a new AP6 device which comes full of RAM.

[SteveF]

Code: Select all

mame64 electron -exp plus3 -exp:plus3:exp romboxp -cart1 aqr -rom2 ..\AP6v131-pad.rom -window

Note that expansion devices are chained, so you need to specify that romboxp is attached to the plus3. The romboxp doesn't have a pass-through expansion port.

Thanks, that works a treat. It's interesting how realistic this is, in that you need to get the chaining right - I guess my lack of familiarity with Electron hardware is hurting me a bit here.

[Pernod]

It's interesting how realistic this is, in that you need to get the chaining right - I guess my lack of familiarity with Electron hardware is hurting me a bit here.

Yeah, it's intended so that you can configure whatever combination of peripherals you want to use, that would work together on a real machine. If it would cause a conflict on a real machine then it would conflict in MAME too. Other emulators just give you a fixed configuration with very limited options to change anything.

I'm getting a little frustrated with the AP5 Tube issue, seems it's never worked in a public release, though I've previously posted screenshots of it definitely working. It's failing to transfer BASIC across the Tube, but am failing to understand why, especially as all the same devices work together on a BBC.

[SteveF]

Is it possible to run an emulated Electron at >100% speed in MAME? I have a slow test case and when I'm testing in b-em I can run the emulated BBC at 500% to speed things up; is there a MAME equivalent? I did have a quick poke on Google but I couldn't see anything, most of the discussion seems to be about MAME running too slowly rather than running it artificially fast.

[Pernod]

Is it possible to run an emulated Electron at >100% speed in MAME?

Yes, select UI mode with ScrollLock then F10 to Throttle (F11 will also show FPS).

[SteveF]

Thanks, that works a treat!

[dominicbeesley]

A quick question: I'd like to get BASIC programs into the Acorn Communicator emulation, what's the best way. I'm guessing I could make a ROM with them in but I'm not sure how I get the emulation to pick up an extra ROM. Failing that is there a way to paste text across from the Windows clipboard?

[Pernod]

A quick question: I'd like to get BASIC programs into the Acorn Communicator emulation, what's the best way. I'm guessing I could make a ROM with them in but I'm not sure how I get the emulation to pick up an extra ROM. Failing that is there a way to paste text across from the Windows clipboard?

Hmm, good question! You can paste from the clipboard, if you open the UI -> Input (general) -> User Interface you can configure the key combination UI Paste Text which defaults to SHIFT+SCROLL LOCK. I'd suggest changing it to something else so that SHIFT doesn't affect what's being pasted. Having said that, it doesn't work too well due to never being tested with the Communicator. If you post a txt file with your program I can try to fix the characters currently not being pasted correctly.

It may be easier to use the debugger to save the memory containing your BASIC program from loading it into a Master at &0E00, then load that memory back into the Communicator at &2B000, assuming Master and Communicator BASIC's are tokenised the same. See https://docs.mamedev.org/debugger/memory.html for debugger load and save commands.

[dominicbeesley]

Thanks Nigel,

The debugger sounds like the easiest and best option. I just want to get ClockSp on there and get a baseline speed. Do you know accurate is the emulation in terms of the 65816 core etc?

D

[BigEd]

(is there any way to use the serial port, modem, or Econet, to load a program?)

[dominicbeesley]

No idea Ed, but the debugger did work.

Here's a screenshot of it running ClockSp...it looks to be quite fast for the 65816 at 2MHz! Nigel, is that what speed it is running at in Mame - it's giving rather better results than I'm getting on my other 65816 machine which is running at about 3.5MHz!?

D

[Pernod]

The debugger sounds like the easiest and best option. I just want to get ClockSp on there and get a baseline speed. Do you know accurate is the emulation in terms of the 65816 core etc?

The 65816 is used in a handful of machines, including the SNES, so would assume it's fairly accurate. The briefcase Communicator has cartridge slots which would probably be ideal for your use, but they're not emulated due to lack of info on them.
If you post a txt file of ClockSp then I'll try to fix any UI Paste issues.

(is there any way to use the serial port, modem, or Econet, to load a program?)

serial: you'd still need write something on the Communicator to receive the data, and something would need to be setup on the host to serialise the program and transmit via a TCP port to the emulated serial interface.
modem: not emulated.
econet: partially emulated, not working.

Here's a screenshot of it running ClockSp...it looks to be quite fast for the 65816 at 2MHz! Nigel, is that what speed it is running at in Mame - it's giving rather better results than I'm getting on my other 65816 machine which is running at about 3.5MHz!?

The 65816 is definitely clocked at 16Mhz/8, so 2Mhz.

[dominicbeesley]

Thanks Nigel,

The Arithmetic module must be better than it looks!

Ooops, the screenshot didn't get attached...

[Pernod]

..., but the debugger did work.

Nice to see a relatively unknown feature being used. It's not something I've ever tried, but good to know it works and has a useful purpose.

[dominicbeesley]

Another question - possibly daft but I can't find any info on it - is there a way to get the emulation speed to show on screen.

I'd like to double check that it's running at 100%. The reason I ask is that I've been scratching my head at the ClockSp test showing a more than impressive speed! I think the reason might be that TIME appears to be running at exactly half speed. I'm just timing

Code: Select all

REPEAT:P.TIME:UNTIL0

with a stopwatch.

Either the mame emulation is going at half speed or TIME is somehow slow - leading to the impressive results!

D

[BigEd]

Oh that would be a disappointment - I was hoping Acorn had done some good stuff using 16 bit operations to speed up arithmetic!

[Pernod]

Another question - possibly daft but I can't find any info on it - is there a way to get the emulation speed to show on screen.

I'd like to double check that it's running at 100%. The reason I ask is that I've been scratching my head at the ClockSp test showing a more than impressive speed! I think the reason might be that TIME appears to be running at exactly half speed. I'm just timing

Enable UI then F11 to Show FPS. The RTC is not yet emulated, maybe it's supposed to sync with it?

[dominicbeesley]

Nigel,

I don't think TIME and the RTC are related: TIME is the centisecond counter which should just count VIA (or whatever) interrupts. I've just checked and the emulation is running at 100% but TIME is at 50%. I'm not sure how this is done on the Communicator is there a VIA or is it all in the ULA - anyway it looks like something isn't quite right in the emulation. I just tried SOUND 1,-15,100,10 and it sounds twice as long on the MAME/Communicator as on the Beeb too.

Ed,

No it's pretty much Basic4.32 with 24bit pointers - I've just posted in another thread with some more details. I'll start a new 65816 BASIC thread some time this weekend.

[Pernod]

I've just checked and the emulation is running at 100% but TIME is at 50%. I'm not sure how this is done on the Communicator is there a VIA or is it all in the ULA - anyway it looks like something isn't quite right in the emulation. I just tried SOUND 1,-15,100,10 and it sounds twice as long on the MAME/Communicator as on the Beeb too.

There is a VIA, but currently only hooked up to the printer port. How does the Electron keep track of TIME, DISP_END interrupt? Maybe I need to look at screen timings?

[dominicbeesley]

I've no idea how it's done on the Electron, I seem to remember it being a true 100Hz timer but it might well be driven by the screen timings, I have a vague memory of there being some demo magic being done half way down a screen.

I tried a simple *FX19 loop but *FX19 doesn't seem to work on the Communicator.

D

[hoglet]

On the Electron there are two seperate 50Hz interrupts from the ULA:
- the RTC interrupt (at the end of line 99)
- the Display End interrupt (at the end of line 255)

Each of these increments the timer, which gives you the 100Hz.

Dave

[Pernod]

On the Electron there are two seperate 50Hz interrupts from the ULA:
- the RTC interrupt (at the end of line 99)
- the Display End interrupt (at the end of line 255)

Each of these increments the timer, which gives you the 100Hz.

Right, the Communicator currently only implements the Display End interrupt. I'll try adding the RTC and test TIME.

[BigEd]

Ed,

... it's pretty much Basic4.32 with 24bit pointers - I've just posted in another thread with some more details. I'll start a new 65816 BASIC thread some time this weekend.

Great - we've both got reasons to be interested in an '816 Basic! See you in that new thread.

[Pernod]

The Arithmetic module must be better than it looks!

I've implemented the RTC interrupt and TIME now looks good, so if you post your memory dump that I can load into the debugger I'll re-run ClockSp for you.