BeagleBoard BeebIt becomes Beta

I’ve finally updated BeebIt, the BBC micro emulator for RISC OS, to version 0.62 so that it runs well on the BeagleBoard. It’s still Beta quality as there is the odd issue, but I have found it stable enough to run with the BBC software I have tested it with. The main issue at the moment is with the sound emulation which is not 100% ARMv7 compatable. Sound does work for most things, but some, such as M128 Elite, will cause the emulator to crash. The solution is to disable sound if it is probmatic.

This version of BeebIt still runs fine on the RiscPC/A7000 and Iyonix.

New features in Beebit version 0.62:

- Added AMX Mouse emulation.
- Fixed corruption on MODE 2 screen when running on the Iyonix.
- Corrected alignment load issues to allow BeebIt to run on the Beagleboard.
- Added higher resolution plotting routines to allow BeebIt to run on the Beagleboard.

Please try it out and report any issues you find. It can be downloaded from:

http://homepages.paradise.net.nz/mjfoot/riscos/BeebIt062.zip

Cheers,

Mike.

—
Michael Foot <mjfoot(at)paradise(dot)net(dot)nz> *
http://homepages.paradise.net.nz/mjfoot/

• Replace letters between () with @ and . when replying

Great news – I’m looking forward to trying this out! Are there any issues with MDFs?

Yeah, I should have mentioned that. It needs Mode 21 (640×512) to run on the BB. The MDF entry I use is:

# 640 x 512 (55Hz)
startmode
mode_name:
x_res:640
y_res:512
pixel_rate:32000
h_timings:76,88,96,640,96,28
v_timings:3,19,16,512,16,2
sync_pol:0
endmode

BeebIt can also run in Mode 15 or 12, but they are not possible on the BB as far I know.

It needs Mode 21 (640×512) to run on the BB.

That’s OK. It’s already listed in this MDF on the OMAPVideo page. What about teletext modes? (Sorry, I can’t try it out for myself for the moment – otherwise I’d actually have a look before asking stupid questions.)

Modes 12 & 15 (and all the other pre-RiscPC modes) should work OK as long as you’ve got a suitable MDF & monitor. At some point I should probably have a play around and see how many of the old modes I can get working, and add their definitions to the list on the wiki.

What about teletext modes?

I wrote a teletext emulator which BeebIt uses on the Iyonix and BB so no problems there. Teletext emulation is mapped to the Mode 15 or Mode 21 screen used for the emulation.

Modes 12 & 15 (and all the other pre-RiscPC modes) should work OK as long as you’ve got a suitable MDF & monitor.

Yes that is true, however I’m not aware of any MDF definitions that allow them to work. Certainly my muddlings with MakeModes has not been successful.

As an aside, I also looked into making BeebIt multitask on the desktop. The main stumbling block was receiving key up and down events which the WIMP does not provide. If anyone has written a module to intercept key up/down events and buffer them, please get in touch. It would save me having to reinvent that functionality.

Cheers,

Mike.

Making BeebIt multitask would be a big improvement, and get round all those old mode display issues on modern monitors.

You could try contacting Christopher Bazley about capturing keyboard and mouse events, as he must have had to solve those problems for the desktop version of SF3000 – http://www.starfighter.acornarcade.com/

Yes, I have been in contact with Chris and do know what he did for SF3000, however while I know what needs to be done, I can’t directly use his solution and was hoping someone else had a more generic way of capturing keyboard codes to save me some work :)

OS_Byte 121 not good enough for you, then?

Maybe there are some features of 6502Em worth considering. Michael Borcherds unfortunately "[doesn’t] have any time for RISC OS […]".

OS_Byte 121 not good enough for you, then?

No. Polling the keyboard 50 or so times a second is not the best way to achieve keyboard emulation.

Maybe there are some features of 6502Em worth considering. Michael Borcherds unfortunately “[doesn’t] have any time for RISC OS […]”.

I have very little time myself to add new features these days either. I haven’t used 6502Em enough to know what features it has that are better or missing from BeebIt. Apart from Electron emulation which won’t be happening as it’s not something I can add in easily or quickly.

I’m pretty sure BeebIt does not have a decent sized userbase who use it regularly anyway so any time spent on it would have to be worthwhile.

decent sized userbase

If it were to be included on a disc image as the modern alternative to 65Host (along with a number of free examples/demos) that might change.

A proper release of BeebIt 0.62 is now available. John K has updated the sound module so it is ARM v7 compliant now.

http://homepages.paradise.net.nz/mjfoot/

under the BBC Emulator link.

Cheers,

Mike.

—
Michael Foot <mjfoot(at)paradise(dot)net(dot)nz> *
http://homepages.paradise.net.nz/mjfoot/

!!DeepKeys augments the WIMP keypress message with internal key numbers and modifier key state which would get you part way there already.

An (optionally timed) keydown/keyup buffer though is trivial to implement. Presumably you only need a mapping of the current state to avoid all the INKEY overhead? Actually I wrote something similar already to get around the unnecessary keyboard debouncing that ruins RedSquirrel and related products – very fast up/downs get debounced by RO so never reach the keyboard buffer. I wrote a module which times every key and automatically prolongs very fast ones until RO deigns to allow them through.

The up/down debounce should be optional, configurable or excised completely for modern chipsets I’d have thought.

The up/down debounce should be optional, configurable or excised completely for modern chipsets I’d have thought.

The USB drivers are able to tell KeyV not to debounce the input (see the use of MagicNoDebounce in usbkboard.c). It looks like you could just call KeyV_KeyboardPresent with the no debounce flag to disable the kernel’s debounce code on an existing keyboard. But it probably won’t help you much since I think it’s only supported by RISC OS 5.

Didn’t test it much, but I see one improvement: !BeebIt’s own MODE 7 emulator should be enabled on the BeagleBoard, at least until the OMAP port of RISC OS gets it’s own MODE 7.

Edit:
Reading the thread again I see that !BeebIt uses it’s MODE 7 emulator on the Iyonix. On the BeagleBoard the MODE 7 emulator isn’t used. Maybe a simple configuration option would be better than a clever detection routine.

!!DeepKeys augments the WIMP keypress message with internal key numbers and modifier key state which would get you part way there already.

An (optionally timed) keydown/keyup buffer though is trivial to implement.

Yes, !!DeepKeys comes close but not completely what I’m after. Anyway, a few solutions have been given to me now, so it’s just a matter of getting onto it and making it work.

The USB drivers are able to tell KeyV not to debounce the input (see the use of MagicNoDebounce in usbkboard.c)… I think it’s only supported by RISC OS 5.

IMHO any debouncing should be pre-KeyV, but it’s certainly the case that in any hosted RO the host will have done any debouncing necessary.

I wrote it for someone who couldn’t get a PC barcode scanner to work with an emulated RO – the keypresses simulated by the Windows device driver were getting through the emulator fine, only for RO to throw them away. I think it probably dates back to the Arc – why would you need it in PS2 days even, never mind USB?

It looks like you could just call KeyV_KeyboardPresent with the no debounce flag to disable the kernel’s debounce code on an existing keyboard. But it probably won’t help you much since I think it’s only supported by RISC OS 5.

From ROL Select documentation here:

Before key presses are inserted into the keyboard buffer by the Kernel a short delay (2 cs.) is enacted. This allows key debounce to be detected and ignored. However, certain input devices are not susceptible to such debounces and this additional delay can be ignored. Kernel versions from 10.23 can have this delay removed by passing a special value in R2 when the keyboard driver is declared present.

So it looks like ROL and ROOL have come up with the same solution…

It’s the wrong solution – how is the keyboard driver supposed to know whether the hardware platform needs debouncing? That’s the device driver’s job.

I agree. But perhaps the rationale was to take debouncing a level higher up to avoid each individual device driver having to do the same job? Not that debouncing is hard to implement… Who knows?

MODE 7

MDF post in ‘RISC OS Build On Touchbook’ thread.