stardot.org.uk

That's a neat idea, but I think (without actually trying it but based on earlier experiences with this routine when I was trying some similar things) it's necessary to have all the entries in the table be "proper" and not stub values. The reason is that in the calculation of 2*x*y by doing (x+y)^2 ...

I've been wondering if precision can be simply improved a tiny amount by just allowing 3 integer bits [-4, 4) instead of 4. If z re or z im >= 2, that's already a bailout condition, before you've even done any squaring. So set table entries for |x| >= 2 to 0, and then after the 16-bit add you can do...

Looks like we've got some smart new icons with the phpBB upgrade!


Nice to see that there's a special one for threads about burnt out caps.

Yeah I already tried that. But just realised that my ad-blocker was hiding the overlay. All good now

Alas, no! I did get a GDPR screen to accept though (which I did).

Heads up - since the upgrade, I can no longer navigate to any link as a popup appears saying: You cannot access links on this board until you have accepted the Cookie Policy. (The only way I was able to get here was by opening each link in new windows each time). Happy to accept the Cookie Policy bu...

It is indeed! Thanks!

Just tried to run B-Em in "ARM evaluation system" mode to see if it worked, but when I try *BASIC, I get: Undefined instruction at 80008058 Register dump (stored at &E40) is: R0 = 00000F00 R1 = 00000001 R2 = 03001570 R3 = 0300156C R4 = 00000F01 R5 = 00000041 R6 = 83000F04 R7 = 00008000 R8 = 00000F06...

I was being facetious! I honestly had no idea that such a thing existed (and assumed it was some kind of typo or something I didn't understand...).

Now I guess I have to ask - why was that ever included in any version of BBC BASIC? And how was it tokenised?!

There's another idea which I'm failing to find in my searches- a little like the boundary following, expect it draws a small circle around each computed point. In areas of less detail, it turns out the circle is not so small, of course. The net effect, mathematically justified, is needing to comput...

Four squarings... it turns out , I think, that three squarings are enough: The one multiply was being used to calculate zr * zi. If we instead calculate (zr + zi)^2 then we get zr^2 + 2*zr*zi + zi^2. Since we’ve already calculated zr^2 and zi^2 we can just subtract them off Out of curiosity, I just...

Oooh, great trick! Kicking myself for not spotting that when I was writing it up! I can actually use that to improve the performance of my code, substantially I suspect!

BigEd wrote:like BBC BASIC's MANDEL command

Did I miss a trick here?

Not at all, I'd totally love to see a 200MHz (or whatever) Pi-based copro blitz through a Mandelbrot render on a Beeb! This being the case, you wouldn't even want to try to share the computation work - just have the co-pro doing the calculations, and host doing the plotting (via a custom WRCH implem...

The border tracing is quite straightforward. Instead of using recursion, it maintains a queue of coordinates to process and carries on until it's empty. First thing it does is pushes all pixels at the screen edge to the queue. Then, for each item in the queue: Evaluate the pixel at that position and...

That's a cool technique! So, we have: Z re ' = Z re 2 - Z im 2 + C re Z im ' = 2 Z re Z im + C im        = ( (Z re + Z im ) 2 - (Z re - Z im ) 2 ) / 2 + C im That way, all the squares come directly from the table. Did you ever see my take on the Mandelbrot set, here ? It uses 32-bit precision, and p...

Yes, I think you're right, that would make sense. I have in effect 255 single line, single row CRTC frames then a block of 57 single line rows with just one visible (intended to be the 256th line) totalling 312 scanlines. If R4=57-1 isn't being latched until the following scanline am I actually gen...

I still don't think this explains what I was seeing at the bottom of the screen because although every row is the first row, it's also the start of a new CRTC cycle so I'd expect it to reload MA. According to what I *think* my timing is (from the b-em debugger) I'm setting R12/R13 during the first ...

BeebEm doesn't model any of this really accurately though (unless it's changed massively since I last used it). I don't even think it has a cycle-exact model for emulating CPU and video concurrently. Moving R4=0 to the previous scan line (6) fixes the issue, but as far as I can tell, anywhere on the...

Thanks guys. RichTW, I think you are correct about somehow missing the end of frame, this would happen if rows were set to 0 before the 6845 had finished the previous frame. My take on it was that maybe R4 is being set to 0 in the first visible row after the CRTC has already decided that it'll carr...

Does the 6845 ever test any value for anything other than exactly equal? That's a very good point. How I arrived at the fix was I added a extra: if (vc >= crtc[6]) dispen = 0; comparison which was executed each time through the video_poll code. That seemed to solve the problem. Then I tried moving ...

This is a really interesting thread, thanks for all the links and info. It is quite timely (pun intended?!) as I’m currently writing a new BBC Master demo that is all based around reprogramming the CRTC liberally. If you want to test anything I have a framework that runs code exactly at the start o...

Incidentally, this documentation has the following snippet about different CRTC types: The MA is reloaded with the value from R12 and R13 when VCC=0 and VLC=0 (that's when a new CRTC screen begin). However, CRTC Type 1 keep updating the MA on every new scanline while VCC=0 (and VLC=<R9). This would ...

I think this is possibly consistent with my suggestion above. You're getting a VSync in the right place, plus you're also getting another VSync about 12 rows later. This could happen if the first R4=0 was arriving too late, by which time the CRTC has already started another cycle (which, this time w...

One thing which is quite neat about your setup is that it should only be necessary to write R7 once ever, because the row counter can only reach that value when it's at the end chunk of the screen. Something to check: make sure that R4 is always getting set to 0 before the end of the first visible r...

So are you actually not getting the VSync signal at all then, according to the scope? I can't see anything wrong with your method, but if you're never getting VSync, my only thought is that the CRTC internal row counter is never reaching R7. Which presumably means that R4 is never getting set to 11....

Oh yeah, sorry I get it. I think your final R4 is one too big. Try with R4=10 (28+11=39).

Edit: oh no, I'm an idiot. You're counting the last visible row in with the rest of the frame.

Sure I'm missing something, but I only count 26 rows there in the frame. Surely R4 needs to be set to 24 at the end, to make up the full 39 PAL rows?

PCM value straight to duty cycle. That gives you an on duration and an off duration for every sample. Then it is just turn on... wait Ton... turn off... wait Toff... repeat. A look up table from sample value to delays works. Really? :o Where 0=duty cycle 0% and 15=duty cycle 100% (or 50%?)? Or some...

Yes, that's been my thought on how to create a worthy sequel: a 6502 second processor version where the parasite runs the game code, physics simulation, map generation, etc, and the host is demoted to a sprite plotting workhorse and sampled sound machine. This way you could have more intricate maps...