Latest version of BeebEm

[evert67]

I was wondering what the latest version of BeebEm is. I have version 4.14 (http://www.mkw.me.uk/beebem/index.html). But this is from 2012 and I have seen quite a few posts on BeebEm on this forum lately. So I wondered if there is a new version.

Thanks!

[ctr]

4.15 is close to being released.

jgh's VDFS changes were a last-minute addition and there is still some discussion. (I'm mungre there.)

And Mike Wyatt has just pushed Music 5000 emulation.

[Deleted User 9118]

Ah, great to see jgh and Mike in there. M5000 in Beebem would be super!

Unfortunately my "physical" beebs have gone haywire so I'm a bit discouraged at the mo.

[Deleted User 9118]

I've done a fresh build from the github stardot master branch but it throws an error in building the installer

5>------ Build started: Project: Installer, Configuration: Release Win32 ------
5> '"\iscc.exe"' is not recognized as an internal or external command,
5> operable program or batch file.
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(203,5): error MSB3073: The command ""\iscc.exe" BeebEmSetup.iss
5>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(203,5): error MSB3073: :VCEnd" exited with code 9009.
========== Build: 4 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Is there some third party bit that I have to add? (I suppose the inno bit)

B.t.w. nice to see the M5000 running

[chrisn]

Is there some third party bit that I have to add? (I suppose the inno bit)

Yes, it's Inno Setup, which builds the installer: http://www.jrsoftware.org/isdl.php. You''ll also need to configure the project to find iscc.exe, details here.

[eelco]

Cool. Good to see that I'm not the only one developing on the BeebEm project. I thought it was kindof abandoned.

I've been working steadily on what I call v4.20 of BeebEm, which includes the 68k co-processors described here. Since I've now resolved a lot of bugs (and since I didn't release this code anywhere yet) I wanted to release this version on my own github page, but I'll put that on hold now.

When v4.15 is released I'll make a git pull request so that this code can be merged

[chrisn]

Cool. Good to see that I'm not the only one developing on the BeebEm project. I thought it was kindof abandoned.

Not abandoned, we've recently put the code into GitHub and there are some great new features and improvements coming in the next release.

I've been working steadily on what I call v4.20 of BeebEm, which includes the 68k co-processors described here. Since I've now resolved a lot of bugs (and since I didn't release this code anywhere yet) I wanted to release this version on my own github page, but I'll put that on hold now.

When v4.15 is released I'll make a git pull request so that this code can be merged

Excellent There's still some work to do to complete 4.15. Your pull request will be very welcome!

[Deleted User 9118]

I've been working steadily on what I call v4.20 of BeebEm, which includes the 68k co-processors described here. Since I've now resolved a lot of bugs (and since I didn't release this code anywhere yet) I wanted to release this version on my own github page, but I'll put that on hold now.

With this bit in it might warrant a bump to version 5.00

Are you planning to wait for the 4.15 release? It looks like the core bits on the github project are now pretty stable.
I'm doing regular builds from the source and run from those.

Why not merge before official release and indeed bump it up to 4.20 or 5.00?

[eelco]

Well, that could be done. But I've been working on some other stuff as well, e.g. untangling all platform-dependant code from BeebEm, and putting it in a seperate folder. This way, in theory, it would be a whole lot simpler to port BeebEm v4.14+ to other platforms like Linux and Mac. IMO it would be a better approach to a multi-platform BeebEm than attempting to merge the existing Linux and Mac branches into the v4.14 branch. This could be a good candidate for a major version update. Would be good to hear how others would feel about this approach (IRC anyone?). I've started with the DFS DLL's though, and I have some success with it.

Other stuff which I've worked on:
* Technomatic Z80 co-pro (beta status)
* Re-integrating i186/i286 co-pro's without the old propriety-licenced code (pre-alpha status)
* Cycle-exact implementation of the i8271/wd1770 disc controllers, so it can support raw disc images

[mjf2708]

I agree with eelco - it would be great to have a multi-platform version of BeebEm. Jon (g7jff) has done a superb job of maintaining MacBeebEm, but as he points out elsewhere, he no longer has a Mac, so any development is being done under emulation (and to his credit, he has just - 22/7 - released an updated version).

[eelco]

I've finally gotten around to putting my development tree on GitHub. Latest development tree can be found here:
https://github.com/eelcohn/beebem/tree/v4.21-rc1

By using C++ objects I've tried to build re-usable code, see the /src/components/ and /src/peripherals/ folders. This way it should be a lot easier to implement new peripherals in the future.

Since it's my development branch, you could run into bugs here and there. Please let me know if anyone finds any.

I hope this fork will one day be merged in the StarDot's BeebEm repository Anyone know what the status of v4.15 is?

[Elminster]

Does you fork only compile on windows at the moment?, you mentioned spliting out version specific files etc. But not sure if that means it will complile on more than just windows.

[eelco]

Yes, at the moment it only compiles on Windows. Splitting out platform-specific code will take a lot of effort, and I've only made a start since AFAIK there are no other attempts at cross-platforming BeebEm.

[Elminster]

Thanks for confirming. I like the idea of bringing them all in line.

[chrisn]

I've finally gotten around to putting my development tree on GitHub. Latest development tree can be found here:
https://github.com/eelcohn/beebem/tree/v4.21-rc1

By using C++ objects I've tried to build re-usable code, see the /src/components/ and /src/peripherals/ folders. This way it should be a lot easier to implement new peripherals in the future.

Since it's my development branch, you could run into bugs here and there. Please let me know if anyone finds any.

I hope this fork will one day be merged in the StarDot's BeebEm repository Anyone know what the status of v4.15 is?

I guess I'm in the position of being the current maintainer for BeebEm for Windows, although the work on v4.15 has come from a few contributors. The GitHub repo is here: https://github.com/stardot/beebem-windows

I'd like to get v4.15 out there soon, but there's an open pull request at the moment for a VDFS feature that still needs a bit of work to complete. We could hold that feature for a future version, bit I'd like to ask jghartson's view on it first.

I fully support any work towards a cross platform BeebEm, this would be great. But I'd like to see that done using the beebem-windows repo as a basis, as this is the most up to date Windows version at least.

[jgharston]

I'd like to get v4.15 out there soon, but there's an open pull request at the moment for a VDFS feature that still needs a bit of work to complete. We could hold that feature for a future version, bit I'd like to ask jghartson's view on it first.

I've been juggling loads of other stuff recently (burst pipe, nephews in Ireland, boundary review report, car died). I should be able to have a look over the weekend. Off the top of my head *DELETE never gives 'File not found', which I've got a couple of note on.

Edit: And how could I have forgotten, some bloody idiot called a general election.

[eelco]

I'd like to get v4.15 out there soon, but there's an open pull request at the moment for a VDFS feature that still needs a bit of work to complete. We could hold that feature for a future version, bit I'd like to ask jghartson's view on it first.

There's no rush, I think it's great that people are developing new features for BeebEm anyways, so waiting for a proper VDFS implementation is the way to go IMO.

I fully support any work towards a cross platform BeebEm, this would be great. But I'd like to see that done using the beebem-windows repo as a basis, as this is the most up to date Windows version at least.

I couldn't agree more, that's why I used the Windows version 4.14 as a basis for my code updates.

[Deleted User 9118]

Is it an idea to post a beta 4.15 over here. In a recent post I saw people having issues with directX like I had before. In my recent builds this seems to be gone.

How far are we off from a release?

[leenew]

Hi,
Does anyone know why the MODE 7 emulation is not correct in "Shapes Game"?
It works fine on a real beeb, JSBeeb, and in B-Em, but the main sprite is corrupt in BeebEm....

Disc073-ShapesGame.zip

(4.19 KiB) Downloaded 123 times

[CMcDougall]

^also the first screen of Revs should be like this :

and also the start of JCB digger when it drives from right to left

[Commie_User]

The latest Beeb-Em on the site has way more stable sound. I'll enjoy that for chiptuning.

[ctr]

I've seen the Revs bug elsewhere and I've been meaning to look at it for a while, so I've pushed a fix.

Sadly, this doesn't help The Shapes Game. That bug looks like a timing problem. The top half of the main sprite is sometimes fine, sometimes flickers and sometimes disappears, depending where on the screen it is.

[vanekp]

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)

[chrisn]

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)

Thanks for reporting this. I have added it to the BeebEm issue tracker on GitHub: https://github.com/stardot/beebem-windows/issues/22

[vanekp]

3D Grand Prix crashes on beebEm after loading GP3 (works fine on B-em) if you turn off ignore illegal instructions it then stops with the following
6502 instruction 0x02 at 0x710A which I guess is an illegal instruction that is not implemented in BeebEm but well in B-em.

[chrisn]

I think 4.15 is almost ready for release... here's a first beta: download.

If beta testing goes well, I hope to publish 4.15 on the official BeebEm website. Please report any problems or issues in this thread, or raise them on GitHub.

Here are the changes from the current 4.14 release:

• Fixed 320x256 screen capture.
• Enabled DirectX full screen display at current desktop screen resolution.
• Consistent file selection dialogs.
• Added debugger Alt-Tab support.
• Added Sprow ARM7TDMI co-processor emulator.
• Fixed sound register latch bug.
• Fixed wrap-around bug with indirect, Y-indexed addressing mode in the 6502 emulator.
• Migrated source code to Visual Studio 2015.
• Fixed crash if sound sample files are missing.
• Fixed 8271 disk emulation to show disks as not ready after motor stops.
• Fixed video recording on Windows 8.
• IDE support:
  • If invalid drive selected can still access IDE command register to select a different drive.
  • SetGeometry sets IDEStatus correctly.
  • Seek returns correct IDEStatus for invalid/absent drive.
  * Z80 support:
  • Torch inrom/outrom selection corrected.
  • Small client ROM loaded multiple times to ensure contents reflected.
  * Z80 CPU:
  • Bugs fixed in IN/OUT instructions and block instructions.
  • Added repeated EDxx instructions.
  • Bugs: BIT doesn't set flags as per real hardware.
  * Music 5000 Synthesiser emulation.
  * General sound emulation improvements.
  * Fixed graphics hold in teletext mode.

[tricky]

I didn't see it mentioned, but the sound desync's from the video in the recorded AVI if vsync is disabled, I haven't checked when not disabled, but I guess as no one has mentioned it, it is probably OK. This maybe just my video editing software.

Locally, I save and reload watches and breakpoints as well as updating their addresses from the labels exported by beebasm, which I also import depending on command line options. This isn't a request, but it is a small change that seems handy when developing.

[FourthStone]

Looking super, that file dialog inconsistency used to *bug* me quite a bit.

One little suggestion, once installed the publisher in Add/Remove programs control panel is Mike Wyatt, any plans to change this to reflect all the hard work by the Stardot community? If so then also changing the support/help/update links to the github page might also be helpful for those wanting to find the source and latest version etc.

Hope to do a bit more testing, otherwise looking really great... super impressed that the installer for this is only 3mb!!

[lurkio]

Raised an issue about the Shapes Game sprite bug.

[FourthStone]

Just noticed a small bug when defining user key mappings, the dialog box is not the right size to display all controls.

Nothing major but just wanted to pass along.