stardot.org.uk

Very few were 50fps, but those that were really stood out. I can think of Contraption, Pipeline, maybe Firetrack? Those that weren't often didn't have a particularly consistent frame rate, or could be less than 25fps. Smoothness of animation didn't tend to be a big concern to Beeb game authors back ...

I've been on B-Em 2.2 for ages now, and a little while back it started performing really badly, less than 100% speed, unless I turned on the Resizeable Window option. I just tried disabling that again, just wondering if you might be experiencing the same problem, and it's back to working at full spe...

This is the same thing which comes back again and again with jsbeeb on Windows. It happens for me every now and then, and normally force-upgrading Google Chrome fixes it. I think it's a bug in jsbeeb though. For example, the sort of thing which it might be is not clearing all of the border from one ...

As cardboardguru says, there are filing system agnostic ways of doing this built into the OS. OSGBPB 8 gets files from the current directory; OSFILE 5 can then be used to get each file's metadata (load address, execution address, length, whether file or directory). If you need to know something very...

Fantastic work Chris! And this is how to write release notes!

@tricky: how does VS deal with all the .s source files? I compile it through MinGW-w64 on Windows and it works fine(ish) (requiring an obscure define on the command line), but I can't imagine VS having any luck with that!

Yes, I was about to say the same! I took a look at the OS disassembly, and REMV seems like the right thing to hook. I guess you'd need to compare X with the keyboard buffer and return A=character with C clear.

I would try a more dirty technique at the emulation level: namely, during paste, I would enable some slightly different logic which would check for PC=&FFE0, and if so, override A with the next character from the clipboard and force an RTS into the instruction register. I can't think of any part...

I prefer the "window as TV/monitor" model, i.e. the window's size remains constant (but user-resizable, constrained to the correct aspect ratio). The borders should display exactly as per the original hardware. But it just sounds like BeebEm has always done this wrong to me.

I wondered if the ratio would give any clues, but 552:640 is 69:80 and 69 isn't a number that rings any bells with me in the BBC Micro context (don't be tempted...). So the origin of this figure is a mystery to me too, perhaps Chris will explain. I assume 552 (46x12) is just arbitrarily including 3...

I don't disagree that many things can be done better offline, and honestly I think in this case it was just as much out of laziness than anything else to have everything in one place. I don't really think there's any other way of scaling 12 pixels into 16 though, unless you want to subtly change the...

Laziness and simplicity I suspect! I mean, you still have to write the code which does that somewhere , so it may as well be part of the emulator initialisation itself instead of needing a separate process to generate the data. In C++ you could get the best of both worlds and do it at compile time w...

I was quite happy with jsbeeb's MODE 7 glyph rendering. Like many other emulators, it builds 16x20 glyphs from the basic 5x9 character definitions in the 5050 ROM. Since we are stretching 12 teletext pixels into 16 screen pixels, we need 1+1/3 screen pixels for every teletext pixel, meaning that a s...

Having considered the midpoint algorithm for a sheared ellipse, my conclusion is that it's perfectly feasible, but a lot more complicated than an axis-aligned ellipse. Firstly, we can only benefit from two-fold rotational symmetry, so, working from the centre upwards, we have to calculate the left a...

So, the equation is at least correct, because here's what we get if we iterate through the domain of Y, calculating X. (This is starting with the second equation, and solving the quadratic in x) Note there are a lot of constants there which could be precalculated. It can also probably be simplified ...

The GXR ROM disassembly looks like a horror to make sense of - I would definitely go with trying to make the maths work first! The implicit equation of an ellipse is: x^2 y^2 --- + --- = 1 a^2 b^2 (a, b being the x- and y- radii) Rearrange to get: x^2 b^2 + y^2 a^2 - a^2 b^2 = 0 (eq. 1) which is the...

I mean, looking at the control points you have to supply, it's fairly clear I think that it is indeed an axis-aligned, sheared ellipse. First point is the centre. Second point is the x-axis radius (y coordinate of the second point is ignored). Third point is the shear offset in x, and the y-axis rad...

Yes, the ellipse is looking rather like midpoint + shear, I agree. The circle is a big surprise though! Although, given that it has to work with different pixel shapes, maybe we wouldn't expect midpoint circle there (essentially it has to be able to draw ellipses of three different ratios, depending...

Things are now rather different from what they were when Bresenham-style algorithms were developed. Then, before integrated Floating-Point Units, integer arithmetic was the only way to get an acceptable performance. Now the overhead of actually getting the pixels to the screen can be so dominant th...

The Ellipse plotting on the Master supports non-axis aligned ellipses: Does anyone have any idea what algorithm this might be using? Here's a possibility: https://scratch.mit.edu/projects/50039326/ There's a midpoint algorithm for axis-aligned ellipses. A sheared ellipse is also an ellipse, so it c...

I'm actually rather pleased that the original BBC Micro's MOS didn't support circle plotting, because I can imagine the arguments there might have been at the time between Acorn wanting to use a simple algorithm like Bresenham's and the BBC's insistence that it plot (close to) a true circle when di...

The Oric's CIRCLE command used naive Bresenham, but with its strange 6MHz pixel clock (with a character cell being 6x8 pixels), its circles were nothing like circular in PAL mode: https://www.youtube.com/watch?v=JX-SUVMOWWY That's definitely a case where they might've been advised just to omit the f...

Anyway, getting back on track, it's not necessary to calculate square roots at all in order to plot a circle. For "sufficiently square" pixels, Bresenham's midpoint circle algorithm, combined with a fast horizontal line filler, are the simplest way to do this (as per the BASIC example I po...

Ah yes, of course! One iteration per result mantissa bit (presumably only 31 bits since the sign is always zero?). I've always loved the elegance and simplicity of this algorithm for what to me is a non-trivial calculation, and its implementation in binary becomes even more straightforward! e.g. sqr...

This is the longhand method I learnt for calculating square roots: 0 2 2 5 2 5 6 --------- -------- -------- -------- | 6 55 36 | 6 55 36 | 6 55 36 | 6 55 36 | | | | | 6 | 6 | 6 | 6 02x2=| 4 02x2=| 4 02x2=| 4 02x2=| 4 ^ ^ | - | ---- | ---- | ---- | 2 | 2 55 | 2 55 | 2 55 45x5=| 2 25 45x5=| 2 25 45x5...

Here's a BASIC filled circle routine I wrote, with the intention of it being very easy to port to 6502.

viewtopic.php?f=2&t=16672&p=259490#p259490

I think BeebAsm actually works the same way too (because laziness 15 years ago). It should really do multiple passes until everything's resolved (catching the horrible edge case where it ping pongs infinitely between two unresolved states), but I never did it. Even though BeebAsm was intended to be ...

It's years since I have written Z80 code, but surely you can do: Right, yes of course. This is because I'm unfamiliar with Z80, but I'd forgotten that (HL) is always a valid source for an operation, instead of a register (so that's a limited way of operating directly from memory). Which way is quic...

The Z80 does have indexed addressing, of a sort. For example LD A,(IY+2) , but the offset can only be a constant rather than a variable. Yeah, I'm aware of IX/IY, but I didn't compare it with 6502 indexed addressing, because it's really a different thing. Going back to accessing a 'struct' with its...

Z80 code can be fantastically neat and compact compared to 6502! I never got used to the lack of indexed addressing though. 6502 makes random access of data easier, via an index register, while Z80 does better iterating in sequence via (HL), incrementing each time. I guess you can also page align yo...

The *FX 210 byte is at address &262 - it's used in the routine at &EB0A to substitute the required sound chip write with one which sets the volume to zero. It seems that setting ?&2CE=0 really does disable all sound processing though - it should free up all of page 8, but it feels like a...