Latest version of BeebEm

[markusher]

That's great Chris. Well done for the updates and maintaining the BeebEm source.

[vanekp]

Thanks to all involved for the latest update and improvements, greatly appreciated

[chrisn]

That's great Chris. Well done for the updates and maintaining the BeebEm source.

Thanks! I took your advice

Thanks to all involved for the latest update and improvements, greatly appreciated

Thanks Peter ... there's more in the pipeline for the next version!

[mad]

Hi Chris,

Thanks for the update!

[lovebug]

has anyone managed to get beebem to compile in code::blocks ? im totally lost

i tried importing the project into codeblocks 20 and when i try to build i get an error message about ld.exe -llibwinmm.lib

------------- edit ------------------

actually turns out all the librarys used by acorn 1770, watford and opus were giving errors
i manuaged to rename all the someName.lib references in the linker for all 3 to libSomeName.a and got all 3 of those to compile to .dll's without error

just the main program now. i think my old gcc may be an issue as its very very old

[lovebug]

quick question, is it possible to single step os 1.2 in beebem ?

im getting some strange results when trying to step through the reset code at D9CD and it looks like its running some code in ram at 1800 ?

i started beebem clean, nothing loaded
in debugger set a breakpoint to d9cd
then pressed f12
stepping through with next i get this

[vanekp]

beebem does not let me single step it, it does all a the following before I can then single step, but is then way past it.

on now you have screen dumps but I see the line just before the 1800 says its entering the DFS ROM so it must be initializing the DFS work space, and running the code it had put there from the DFS ROM.

[chrisn]

To single step in the OS, tick the "Attach debugger to OS" box.

[lovebug]

thanks vanekp this is good to know at least I know its not just my beebem build at fault as recently I made some changes to 4.17 for new video recording modes and added back the tms5220 speech and I thought maybe I had broken something

I was trying to find a clean way to exit my ladybug game without clearning memory so I could implement saving settings and high score and I really wanted to see what is going on during reset

i'll take a look at the beebem source and see whats going on

[lovebug]

ah ! somehow I missed this

theres a tickbox attach debugger to os in the debugger window !!!! DOH!

does the job nicely

[lovebug]

To single step in the OS, tick the "Attach debugger to OS" box.

I missed your post sorry and thanks

[vanekp]

ahh that explains it, also just learnt something new.

[richmond62]

-
I wonder how [MacOS 12 beta 7] I can choose 'user defined layout'?

[mad]

when taking screenshots...
**sometimes** part of the picture is missing in the BMP file.

[richmond62]

I assume (?) you are taking screenshots on Windoze as no-one else is using clunky, outdated formats such as BMP.

[tricky]

My primary format is TGA, which is pretty old and a little clunky, but so much simpler and the code to handle them negligible.

[lovebug]

its .png for me

[tricky]

Me too for work and sharing.

[chrisn]

Windows BeebEm supports screen capture in BMP, GIF, JPG and PNG formats. The default is BMP but perhaps PNG would be more appropriate. Will see if I can fix the bug that causes part of the image to be missing.

[mad]

Thanks Chris,

I think the screen shot problem is the Mode7 refresh rate.
other screen modes seem ok, and i have not had any problems with those yet (gif/bmp).

then i played Shapes Game, and noticed a problem with the ship character graphics disappearing during play.
so i am definitely on the right track.

[lurkio]

I'm using the latest version of Win BeebEm (under CrossOver (a WINE wrapper) on a Mac), and I notice that the Capture Screen menu command seems to produce MODE7 screenshots with a different aspect-ratio than the one you see when you're actually using the app to play a game, etc.

Here's an example screenshot taken using the Capture Screen menu command in BeebEm:

But here's what the same screen looks like when you're actually playing the game. I took this screenshot using the Mac's native screenshotting function, and it looks more like a "natural" mode-seveny type of aspect-ratio to me:

I wonder if it's worth tweaking the Capture Screen feature in BeebEm so that the aspect-ratio of a MODE7 screenshot matches what you see during normal in-app use?

[lovebug]

there is something wrong with mode 7 for sure, i too have seen the ship 1/2 disapeer in the shapes game during game play
and just a few days ago I used the screen capture for something i was working on and got a missing line for the first time

[mad]

I LOVE the mode7 screen snap with a clean pixel sharp square font.
that's one option that needs to stay.

i am currently resnapping all the mode 7 screenshots for a frontend.

the option is still available if you want a random font size.

[lurkio]

I LOVE the mode7 screen snap with a clean pixel sharp square font.

It's not bad, as such, but I don't think the MODE7 font is displayed in the correct aspect-ratio in the screenshot.

the option is still available if you want a random font size.

Yes, you can select the "Capture at Display Resolution" option, but then the font looks quite blocky and unsmooth in the screenshot, even though the aspect-ratio seems to be correct:

[Deleted User 9295]

I don't think the MODE7 font is displayed in the correct aspect-ratio in the screenshot.

Indeed. I think we've done this issue to death previously, so I don't want to reignite a contentious topic, but MODE 7 pixels aren't square (the square-pixel sampling rate is about 14.75 MHz whereas MODE 7's is 12 MHz) so a capture ought not to make them appear square.

If you don't like the 'blurring' associated with sample-rate changing, the capture can be saved in a high resolution format that can more accurately represent the true pixel shape.

[mad]

I think we've done this issue to death previously, so I don't want to reignite a contentious topic

yes it has.
while i do agree with the technical sampling rate info, and i very much respect your opinion.

in an emulator, we don't need to put up with an inferior blurry display, just because...

i think the best option is to make a predefined font at the correct aspect ratio, and use that.
or have emulator options for both display methods.

it was suggested using a BMP file with the font at 16x20 to get a 640x512 mode 7 screen.
this could be edited by the user in a paint program for their desired bold or thin fonts.
but that option is up to Chris to decide, if he wants to program his emulator that way.

personally, i would even be happy with the display at the incorrect aspect (same as the screen shot).
but i am probably the only one who does.

[Deleted User 9295]

it was suggested using a BMP file with the font at 16x20 to get a 640x512 mode 7 screen.

Yes, that was my preferred solution (and it's the one adopted in BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy), but it did not find much favour here as it was seen to be not in the spirit of an 'emulator' in not preserving the character shapes with sufficient precision.

Mind you if you really want authenticity you would have to take account of the quirks of the circuit which generates the 12 MHz MODE 7 clock from the 16 MHz clock, which certainly doesn't produce a perfect waveform. But that would be taking emulation to ridiculous lengths in my opinion.

As you say a 16x20 character set could be used solely for the capture feature, although that also might be considered not sufficiently 'authentic'. If you want a pin-sharp capture whilst preserving the precise character shapes the only way is to generate a high-resolution image, with many megapixels.

[lurkio]

I don’t fully understand the technical details of how MODE7 and BeebEm work, but, speaking for myself, I’d be quite happy if Win BeebEm could produce a screenshot that looked like the second screenshot in my post above, the quality of which seems fine to me.

I took that second screenshot by using the screenshot function of the host OS, so I presume BeebEm ought to be able to replicate that functionality somehow..? But maybe it’s not that easy. I don’t know. As I said, I don’t understand the technicalities. In particular, I’m not sure why the first and second screenshots in that post look so different. (The font is narrower in the first than in the second.) I guess that the complexity of the image processing pipeline in BeebEm means that there isn’t an easy solution to this problem.

[Deleted User 9295]

I took that second screenshot by using the screenshot function of the host OS, so I presume BeebEm ought to be able to replicate that functionality somehow..?

Is your "host OS" doing High DPI scaling? If so the screenshot image will be a significantly higher resolution than BeebEm's internal bitmap, and whilst it could replicate that functionality it would need to know what the native resolution of the screen is, which is not something that such an application usually knows.

For example on this Windows 10 laptop PC (with 250% scaling) capturing BeebEm's window using Alt+PrtScr results in a 1604x1410 image, whereas BeebEm thinks its output is more like 642x564. Effectively the OS is doing what I suggested BeebEm could do which is to capture an image at a sufficiently high resolution that the MODE 7 characters are both sharp and the correct shape.

Assuming this is what is happening on your PC, you could try switching off the High DPI scaling for BeebEm (in Windows it's under Properties... Compatibility... Change high DPI settings) and then see what the screenshot image looks like.

[lurkio]

Is your "host OS" doing High DPI scaling?

Not sure. I'm using CrossOver on a Mac.