stardot / beebem-windows Goto Github PK

B-Em implemented support for the Hybrid Music 5000 albiet it used an implementation based on some FPGA work and another Emulator called Beech.), as well as some additional support for the MIDI inteface to Native OS!

Would it be feasible for the code base to be examined so that Music 5000 support could be added to BeebEm as well?

Have had a couple of requests recently for adding support for use of Xbox controllers with BeebEm. I guess some of the Xbox inputs could be mapped to the analogue joystick inputs of the Beeb. The Win32 joySetCapture() implemented in BeebEm does not work with Xbox controllers.

Have received a bug report regarding the disc type / catalog check performed when a disc image is loaded:

'Just to let you know i think there is a possible bug in the disc Warning message? When using some games which have been converted into separate game discs (SSD) from Mick Brown's compilation discs (DSD), Beebem shows the message:

"WARNING - Incorrect disc type selected?
This disc looks like a double sided disc image."

after clicking OK to skip the message. The game loads without error.'

One example disc where the warning is incorrectly given is Wallaby: http://bbcmicro.co.uk/game.php?id=72

Looking at the disc content, there is a BASIC program in the sectors where a second (DSD) catalog would be - and the checks made by the catalog check code are incorrectly interpreting the data as a catalog. Suggest this catalog check is just disabled - it was added way back when there were quite a number of disc images with incorrect (or .bbc/.img) file extensions. There are far fewer of these around these days.

Save state/load state doesn't completely reset state and video timing can miss-match.
This can be seen in games like Pacman https://stardot.org.uk/forums/viewtopic.php?f=53&t=20865
Where after a save state + load state, there is usually somewhere on the screen that Pacman will disapear.
I think that this might be due to VideoState not being restored and instead just re-initialised.
I think this is then causing the the position of the raster to be in a different place (probably start of screen).

If you save (comms, tape control, Record) a file within BeemEm to a tape file (UEF) the last byte 2nd byte of the block CRC gets repeated twice, ie 👎
32 35 36 3c 3e 30 20 80 20 a6 2d 32 35 36 3c 3e 50 cf 10
above the "50 cf" is the crc of the block
32 35 36 3c 3e 30 20 80 20 a6 2d 32 35 36 3c 3e 50 cf cf cf 10
above when saved in BeebEm it adds the cf twice to the end of the block so you get "50 cf cf cf".

See this post. The FSD format is documented here. Also of interest is RichTW's fsd2fdi project.

As discussed over on stardot at https://stardot.org.uk/forums/viewtopic.php?f=2&t=19975&start=120#p283455, on BeebEm 4.15 in Integra-B mode, selecting a non-existent bank using &FE30 and writing to it appears to write to the lowest write-enabled RAM bank. There's a test program there which I've also attached here; when run with banks 0-3 empty and bank 4 containing writable RAM, I would have expected this test program to output "B" but on BeebEm in Integra-B mode it outputs "A".

KenLowe has tested this on real hardware and he sees "B" output; his commments are in that thread on stardot.

integra-b-test.zip

I hope this makes sense, let me know if you need any more information. Cheers!

When an ADL style disc is loaded in Drive 0, it is not (currently) possible to export/import a file on the disc to the native OS.

The desired behaviour would be to allow this import/export in a future release.

From https://stardot.org.uk/forums/viewtopic.php?p=304006#p304006:

Could I ask if it is possible to improve the MODE 7 screen capture?
Presently, lurkio does most of the MODE 7 screenshots for bbcmicro.co.uk with an external image editor as the ones that I capture directly from BeebEm do not look that good for some reason?

and https://stardot.org.uk/forums/viewtopic.php?p=304012#p304012:

Also, has anyone else noticed that often the screenshot captured is not what is present on screen when you actually capture it?
In other words, often some "pieces" of the graphics may be missing.

Per this question, add a BBC Model A emulation mode.

Beebem crashes on startup at end of install and trying to run beebem afterwards.
I've built it locally with VS2017, I only have 6, 12, 13 and 17.
To build it from the .sln, I had to:
#define WIN32 (the code deos #ifdef WIN32 #include <windows.h>, but windows.h is what is supposed to #define WIN32, it would be better to #ifdef _WIN32, which is supported by MSVC and gcc.
#define _CRT_SECURE_NO_WARNINGS to remove the warnings (or replace all the function calls).
Swap the character set to multi-byte instead of unicode (I always do this anyway!)
I'm now seeing that the error is that m_DD2 is null in UpdateSmoothing, I suspect that this is because the config file has smoothing enabled, but beebem is not using DX as I have seen this bug in earlier versions.

BeebEm does not define file type icons for .SSD/.DSD and nor does it provide file association definitions.

Attached is a zip file containing:

• The master files in Inkscape SVG format
• The icon files, to be placed into the Icons subdirectory of BeebEm’s application folder
• The necessary Registry changes to define all the file types correctly (Windows Vista onwards; XP’s method stank)

Or at least, would be if Github actually worked.

For DFS, this is easy: BeebEm automatically mounts a disc image included on the command line.

For ADFS, there is a problem. Chances are, the user does not have ADFS installed in the Model B mode, and after they switch to Master 128 mode, all mounted discs are unmounted.

It is not possible to specify Master 128 mode on the command line. Thus, the options are:

a) reinstate the ability to choose the model, so that the ADFS file types will launch BeebEm in Master 128 mode
b) introduce a setting to state which model should be used when the program is launched using an ADFS image, defaulting to the Master 128 — this has the benefit of allowing the user to work with ADFS on the Model M without needing to redefine the file association

The icons are all marked as public domain in the SVG masters, and are all my own work, measured from scratch. They do rely on the MV Boli typeface; if there is a free alternative that would be preferable, I can use that. It just happened to be one that looked right that I had to hand.

Some games available at bbcmicro.co.uk have been patched to detect BeebEm, mainly to overcome issues with BeebEm's graphics emulation.

See this thread for more info ("location &FE10 contains 100 only in BeebEm"). Here's an example:

220 .bbc
230 LDA&FE10:CMP#100:BEQfixthegame:JMP&5600
240 .fixthegame SEI

Audio gets slowly ahead of video the longer the capture.
I haven't tried with interlace.

https://www.stairwaytohell.com/bbc/archive/diskimages/Incentive/WinterWonderland.zip

For comparison, here's how it appears in JSBeeb:

bbcmicro.co.uk has a patched version: http://bbcmicro.co.uk/game.php?id=882

Add some validation? See http://stardot.org.uk/forums/viewtopic.php?f=4&t=14378

The "Happy 35th Birthday, BBC Micro" demo from http://regregex.bbcmicro.net/ draws text incorrectly with the ARM7TDMI coprocessor enabled.

Please add support for the second fire button when using a single joystick.
You could support both buttons on both joysticks, buy for example reversing the order of the buttons on the second stick.

See https://stardot.org.uk/forums/viewtopic.php?p=303996#p303996

I'm still having problems however when I capture a video though...(I'm running this on Windows 10)
It appears to capture ok, but when I try and play it I only get sound but no picture.
Loading it into Media Player Home Cinema it shows me the error attached....

This was removed after BeebEm 4.03 due to licensing issues with files from MAME. Now that MAME uses open source licenses (the relevant files are all BSD licensed), we can safely reintroduce Master 512 186 coprocessor support using the latest code from MAME.

The BeebEm is always on top of other windows after returning to windowed mode from full-screen when using the DirectX9 renderer. This behaviour is not shown using DirectDraw or GDI.

As reported by vanekp on Stardot:

Another funny I have noticed with BeebEm is with loading tapes, if the very 1st file has a sync bit in the leader beebem does not recognise the 1st file and see it as a non-standard block, if you take the same uef file and use B-em it loads the 1st file without a problem, if I take the wav file and remove the sync byte then it works without a problem in BeebEm. (I am using the lates version from the site BeebEm Ver 4.14 Feb 2012)

Will the undocumented or extra opcodes be supported in the latest version of BeebEm
as some programs will not load/run because of unsupported codes. e.g. 3D Grand Prix(Software Invasion) works in B-em but not in BeebEm

Double clicking on a disc image used to load and boot the image. V4.15 no longer auto-boots the disc.

I use colour comments in my code to find sections more easily
If I copy and paste below into BEEBEM it displays in the first instance with colour but on subsequent listing character before the TTTT... is missing. so colour is lost

the same is true for M/C comment
L.
10REM"…TTTTT"
20"„YYYYY"

When using OSWORD &7F or OSFILE, the last byte of every(+) track written to disk is 00 when using Opus DDOS 3.45, although logging shows the correct values are sent to the FDC.

The same is not true when using Acorn DFS 2.26.

I can't see anything different in the order that FDC registers are read/written during successes and failures so I'm guessing it's timing related.

(+)
If I perform these OSBYTE &7F calls:

• write track 77 with 10 sectors
• read 10 sectors back from track 77 (and compare)
• write track 78 with 10 sectors
• read 10 sectors back from track 78 (and compare)
• write track 79 with 10 sectors
• read 10 sectors back from track 79 (and compare)

tracks 77 and 78 writes a zero as the last byte on the track (disk image file shows that either 00 has been written or nothing was) and track 79 is correct when it's read back.

I've tried this with BeebEm versions as far back as 4.03 and it's the same.

I've also tried reducing and increasing the delay in DDOS between writing the last byte to the data register and sending the Force Interrupt command, but no change.

I'm happy to go and hunt down the relevant bit(s) of code in the FDC emulation; just wondering whether someone might (1) already be looking at this or (2) have a bit of insight into where/why this might be happening. I can see there are a couple of Opus-related comments in disc1770.cpp.

Thanks
:)

If you double-click a .SSD to launch BeebEm, and if the .SSD has a !BOOT that CHAINs a BASIC program that immediately uses VDU14 to activate paged scrolling mode (which requires the user to press Shift to scroll the screen in the emulated Beeb) before printing an infinite list of numbers, then the simulated Shift keypress (which I assume is BeebEm's way of implementing a Shift-Break to boot the disc-image) is held indefinitely and causes the screen to keep scrolling until the user presses an actual key. (This behaviour is incorrect.)

Try pressing Shift-Break to boot the disc-image manually to see the correct behaviour.

More details here:

http://www.stardot.org.uk/forums/viewtopic.php?f=4&t=14581#p194938

JSBeeb has the same bug:

mattgodbolt/jsbeeb#166

The Hitchhiker's Guide To The Galaxy speech-sample program uploaded here just results in audio noise (hiss and static) when run in BeebEm.

Although BeebEm's emulation of the Beeb's sound chip may be correct, a better model of the sound waves produced might be required -- it says here.

Add a command line option to load debug symbols, output from BeebAsm's -d option

Dumps all global symbols in Swift-compatible format after assembly. This is used internally by Swift, and is just documented for completeness.

(Feature request from tricky at ABUG, more detail here)

When using analogue moust stick, allow the right mouse button to be the second fire button

The cursor is not being disabled when it should be in Wizzy's Mansion

https://www.stairwaytohell.com/bbc/archive/diskimages/Audiogenic/WizzysMansion.zip

Hi,
The solidisk sideways ram had a number of sw ram banks, which were selected by bits 3:0 of the user port B,
which was located in memory at address $FE60 ( DRB ) and address $FE62 DDRB.
By loading $0F in the DDRB register, the bits 3:0 were set to output .
By then setting the output register to x0, bank 0 was selected, setting to x1, bank 01 was selected,
and so on till $xF, which selected bank $0F ( if available ).
I had the ADE+ macro assembler and the MMU, memory management unit, both intended for use in SW Ram.
I loaded the 2 files in SW ram using a !Boot file like this:
?&FE62=15 -user via bit 3:0 = output
?&FE60=08 -select bank 8
*LOAD ADE+ 8000 -load desired rom
?&FE60=09 -select bank 9
*LOAD MMU 8000 -load the next rom

One could setup ADE+ to use more or less of the sw ram as buffer for the source file,
to handle large files, and / or use an amount as printerbuffer.
The MMU took care of this, using the user via to select the used sw bank.

At present, this is not possible.
Ofcourse I can load the rom images, using the rom config editor, but ADE cannot use the swr to its full extend.

Any ideas if and how this can be implemented?

There's a typo in beebwinprefs.cpp which results in the DiscsPath always being overwritten with the default string.

if (!m_Preferences.HasValue("DiscPath")) { m_Preferences.SetStringValue("DiscsPath", "DiscIms"); }
should be

if (!m_Preferences.HasValue("DiscsPath")) { m_Preferences.SetStringValue("DiscsPath", "DiscIms"); }

The beta version of BeebEm posted here doesn't solve the problem of the corrupted MODE 7 sprite in the Shapes Game as reported here.

By fiddling with the CRTC registers it's possible to persuade a model B to use &3C00 instead of &7C00 for mode 7 screen RAM. I've written a bit more about this on stardot (https://stardot.org.uk/forums/viewtopic.php?f=54&t=20149) and there's a "real" program which uses this feature attached to this stardot post: https://stardot.org.uk/forums/viewtopic.php?f=2&t=19975&start=300#p292963

Would it be possible to add support for this to BeebEm please?

BeebEm crashes if you open a new disk image while the emulator is loading from disk (using the 8271). This happens because the memory for the current disk image is freed and the emulator access the freed memory via a dangling pointer.

The dialog box shown when defining user key mappings is not the right size to display all controls:

Another issue is that this dialog box seems to be shown at a random location on the desktop. Ideally, it should be centred over the parent "User Defined Keyboard mapping" dialog box.

There's current no easy to examine the contents of an SSD disc without using emulator hosted tools.

Would it be possible to have this an option?

(Aside: I was intrigured as to what's actually on a disc at a logical level below the file system. Currently most image formats excepting FDI don't include this.)

I am wanting to have multiple Beebem data directories for development work (specifically wanting to have separate hard disc images). I have used the -Data

On further investigation, it appears that -Data sets the UserDataFolder key in the registry.

It would be really useful to be able to run multiple Beebem instances, each with custom configurations. Is this already possible, or if not, please could this be considered as a feature? Perhaps having a -DefaultData parameter to write to the registry, or -CustomData to specify a configuration at runtime?

Thanks for considering.

BeebEm uses rand() to generate random numbers for the noise channel in the sound generator. It should emulate the SN76489's LFSR - see this thread for more details.

See https://stardot.org.uk/forums/viewtopic.php?f=4&t=9805

Results from using this test SSD: https://github.com/mattgodbolt/jsbeeb/blob/master/discs/Irq-Timing.ssd:

• Real BBC B: 1068
• BeebEm with Basic Hardware Only enabled: 1580 (excludes serial and A/D converter)
• BeebEm with Basic Hardware Only disabled: 1655 (includes serial and A/D converter)

This was removed after BeebEm 4.03 due to licensing issues with files from MAME. Now that MAME uses open source licenses (the relevant files are BSD licensed), we can safely reintroduce speech support using the latest code from MAME.

The audio also starts quiet and after a few seconds gets louder, but seems to have added hiss, which happens on either XAudio or the other option.
I don't know where the noise is coming from, I have no mic etc attached.

http://bbcmicro.co.uk/game.php?id=89

The top line has scrolled out of view:

For comparison, here's JSBeeb showing the same page in the instructions:

When saving a tape uef from BeebEm it adds 2 extra bytes on the block CRC i.e. Frak loader program end 1st block should be 74 (F4 95) 10 but BeebEm has 74 (F4 95 95 95) 10.
This is not a new bug but a long standing one in BeebEm.

See https://stardot.org.uk/forums/viewtopic.php?f=4&t=17509

The attached disc contains two BASIC programs PASTE and PASTE2. Both read from the keyboard using OSBYTE &81; PASTE invokes OSBYTE directly while PASTE2 uses BASIC's INKEY(0) to do the job. They both exhibit the same problem: when pasting text in they just output a constant stream of ASCII code 13s. Typing at the keyboard works fine. (This works in b-em for both typing and pasting text, for what it's worth.)

Would it be possible for the paste functionality to support this please?

(This came up in the context of pasting user commands into the Ozmoo Z-code interpreter; see https://stardot.org.uk/forums/viewtopic.php?f=2&t=19975&p=296258#p296248.)

paste-problem.zip