[rooster]

vaman, on Oct 9 2006, 12:15 PM, said:

has it been tried with Citadel. I'll check it tonight I hope. But it would be good to know it can run, never did complete it when it first came out.

I just tried it with Citadel and it works a treat. I OCed it 270mhz. I see it automatically OCs to 250 in the source there critical :)

as soon as critical gets the save states going I'm gonna be trying to complete it, it was a massive game and one of my favourites on the BBC.

[critical]

rooster, on Oct 9 2006, 01:56 PM, said:

I just tried it with Citadel and it works a treat. I OCed it 270mhz. I see it automatically OCs to 250 in the source there critical :)

as soon as critical gets the save states going I'm gonna be trying to complete it, it was a massive game and one of my favourites on the BBC.

Indeed. As I mentioned before, it was done for my own entertainment primarily, so I wanted it to work at a reasonable speed right away. I can work on the rendering slowness and remove the need for overclocking, I'm sure. I've got save states working on my GP2X at the moment - hopefully I'll do a release this afternoon / evening.

I'm really pleased I bought a mains power adaptor recently... I was finding having to either charge batteries or keep switching on/off to do development was the main block to my working on stuff for the GP2X so much. My other handheld development toy hasn't been switched on for a couple of weeks now :)

[critical]

rooster, on Oct 9 2006, 01:56 PM, said:

as soon as critical gets the save states going I'm gonna be trying to complete it, it was a massive game and one of my favourites on the BBC.

Please try out version 0.3.0 now (see edited first post) :)

[rooster]

superb. just got v0.3.0 - gonna have a good play with it this morning.

thanks for making saves 'per game' btw, i was really hoping you'd do that rather than 1 save for the whole emu good job.

Critical, i was thinking... if your emu is based on the Dave Eggleston's v0.0.11 SDL port, which as he says on his site is based on the latest BeebEm v0.34 then this is a VERY compatible emu right away. Not surprisingly everything I've tried on CriticalBeeb runs fine so far.

I wanna try the infamous games that do ugly interrupt trickery like Revs and Firetrack now. I have faith!
Gentlemen, to the testing labs!

[Gruntfuggly]

Would it be possible to link the keyboard config files to the disc image names? Ie, look for the same name, but with the .kbd extension?

[critical]

Gruntfuggly, on Oct 10 2006, 09:41 AM, said:

Would it be possible to link the keyboard config files to the disc image names? Ie, look for the same name, but with the .kbd extension?

It would be possible, but I thought it'd be less hassle as it currently is.

Things will probably change to the scheme you suggest (which is used by pspbeeb, etc.) when the virtual keyboard and on-device keymap editing are in place - it's more sensible then.

Until then, the keyboard config files may now be linked to the disc images by using the new "Save settings for game" menu item. When you've made the association using that, whenever you load a disc which has a linked keymap, it'll select it.

[Gruntfuggly]

Great - that probably works even better actually - means you can use the same keyboard file for many games.

What do you think the prospects are for improving speed and sound?

[critical]

Gruntfuggly, on Oct 10 2006, 10:38 AM, said:

Great - that probably works even better actually - means you can use the same keyboard file for many games.

What do you think the prospects are for improving speed and sound?

I'm working on the CPU and rendering code at the moment. I've had some encouraging results from changing the rendering / scaling and removing some inefficiency from the 6502 core. Ideally it would be great to integrate the 6502 asm core from ljp or somewhere else, but that won't happen overnight, if at all. I'm concerned about the impact it might have on compatibility too.

[Gruntfuggly]

Sounds promising - it would be awesome to get this running full speed with sound!

Can the shoulder buttons be mapped in the keyboard files? Also, can the GP2X buttons be mapped to multiple BBC keys?

...and lastly, what key is the equivalent of the BBC ']' (closing square bracket) key? I tried RIGHTBRACKET but it didn't seem to work (in Labyrinthe)...

[critical]

Gruntfuggly, on Oct 10 2006, 12:55 PM, said:

Sounds promising - it would be awesome to get this running full speed with sound!

Can the shoulder buttons be mapped in the keyboard files? Also, can the GP2X buttons be mapped to multiple BBC keys?

The shoulder buttons can't be mapped in keyboard files. I didn't implement that, because I needed a trigger to open the virtual keyboard. I guess I could just use the R trigger for that, and let people map the L trigger. Alternatively, I could use the SELECT button to bring up the virtual keyboard, and allow mapping of both triggers. That might be a bit tidier.

Quote

...and lastly, what key is the equivalent of the BBC ']' (closing square bracket) key? I tried RIGHTBRACKET but it didn't seem to work (in Labyrinthe)...

That's not currently mapped, but I think I know how it should be done. That'll be available in the next release (along with performance enhancements).

Cheers for the feedback.

[Gruntfuggly]

Would it possible to map the virtual keyboard button through the keyboard config files? If not, I'd definitely prefer the Select button...

Looking forwards to the next release!

[critical]

Gruntfuggly, on Oct 10 2006, 04:30 PM, said:

Would it possible to map the virtual keyboard button through the keyboard config files? If not, I'd definitely prefer the Select button...

There's no reason why it couldn't be made configurable, but it's unusual to see such a feature in handheld emus, I think. I'll shift it to the Select button in the next release, as I agree it'd be nicer there.

I've just uploaded 0.3.1 (see edited first post). You can play Labyrinth now. Please let me know if any of the rendering is screwed on anything, as I've made some changes to it. I've tried Snapper, Frak, Labyrinth, Jet Set Willy and maybe a couple of others, and they seemed unaffected.

Keep your ideas coming!

[Gruntfuggly]

You haven't changed the link, but it wasn't too hard to figure out...

... downloading and testing now...

[rooster]

critical, on the beebem site the guy says (I paraphrase) if the master compatible v0.34 runs slow try running the older, model B only version.

i'm sure there's lots of reasons why master compatibility might slow things down.
anyway I was just looking through beebmem.cpp and i found this on memory writes:

// BBC B Start
if (MachineType==0) {
if (Address<0x8000) {
WholeRam[Address]=Value;
return;
}

if ((Address<0xc000) && (Address>=0x8000)) {
if (RomWritable[ROMSEL]) Roms[ROMSEL][Address-0x8000]=Value;
return;
}
}
// BBC B End

so every single time a model B opcode does a memory write it also goes through this if (MachineType==0) test to check its not a master or a B+

what do you think? I know its only a cycle or two for the ARM to do this test but if its occurring every single time the 6502 does a mem write would it slow things down!? I thought it might.

obviously taking it out interferes with master compatibility maybe there could be several executables, like mame ?? one for the model B with no master checking and vice versa. just a thought ;)

also, the bit I've highlighted below (for ROM writes) in bold is not needed, its redundant cos of the previous if test:

if ((Address<0xc000) && (Address>=0x8000)) {
if (RomWritable[ROMSEL]) Roms[ROMSEL][Address-0x8000]=Value;
return;
}

(although I think this last one will make no difference to speed! i know games don't try to switch ROMs much :P )

keep going critical !

[critical]

rooster, on Oct 10 2006, 05:50 PM, said:

critical, on the beebem site the guy says (I paraphrase) if the master compatible v0.34 runs slow try running the older, model B only version.

Indeed. I've been taking such things out of the 6502 core to help a bit.

I'll go through the mem handling as you suggest... every little helps :)

I don't really see the need for Master compatibility... I'm just going to keep paring things down until it's as lean as possible.

Gruntfuggly: cheers for that - I've fixed the link now. I just realised I didn't bump the version in the menu either - it's going to go in the build so I don't forget now :)