stardot.org.uk

Oh... you guyz... Thanks for the kind comments! I actually may have some time to pick up some old Beeb stuff soon. But I know I'm terrible for abandoning projects and letting them rot once the interesting stuff is done. The Blurp video you linked to was the first demo with smooth scrolling, which un...

That's exactly the code I had in mind as a way to squeeze the rainbow owl logo into the OS ROM. I'm tempted to give it a go... If you decide to do this, remember to patch up the code around &CBC1 which sets the address within the unrolled loop! But beware - there are some games, e.g. Contraption, w...

My guess is that they wanted to make this as fast as possible to make MODE changes less ugly, but it doesn't really work as you still see the old screen for a couple of frames while it clears. By the Master OS, they abandoned the unrolled loop anyway, and it just does a straightforward top to bottom...

A lot of the Basic maths code is written unrolled, when it could be just as easily written as a loop. A quick browse of the disassembly shows floating point and integer addition and subtraction, floating point comparison, and scratch space clears and copies (among many others) to be routines which c...

Yeah, my take on this is that Repton was just a style of game which worked incredibly well on the Beeb hardware, given its hardware scrolling capabilities, which is probably also why there were a good few games of a similar style (Ravenskull, Pipeline, Clogger...). This style conversely didn't lend ...

you could fit the screen nicely in a sideways RAM bank (or indeed two, for double buffering), and keep all of main RAM free for code. Only the part of the screen where action happens need be double buffered, whilst the part of the games screen used for the score, lives etc. need only be single buff...

Always seemed to me that the Beeb's screen modes were unusually big. I once had the idea that, if you capped the max screen size to 16k (to give 25 line screen modes, which was pretty much the standard size on other 8-bit platforms), you could fit the screen nicely in a sideways RAM bank (or indeed ...

One way it could've been done is to put the code and data into the I/O memory mapped area and only activate it as I/O on the first data access. Would require hardware mods of course.

...and what sort of projects do you imagine you'd like to do with one? I'd like to find time to learn Rust, as it tickles my performance bone, and it might relieve some of my frustrations with the monster of a language that C++ is growing into. Also I really fancy getting to know a functional progra...

I treated myself to one of these recently, as it was on offer in Spain for Black Friday. I'm really happy with it so far - it's only a 15.6" screen, but it's 120Hz Full HD, and has some nice specs including 16Gb RAM, a 128Gb SSD + 1Tb HD, an i7-8750H processor and a GTX 1050 graphics card. All that ...

Looks lovely! Great to see such smooth horizontal scrolling on a Beeb. It's a shame that the background colours are reduced now (presumably the two bitplanes trick like Firetrack), but I wonder if there's scope to add some colour interrupts in there (as ridiculous as that sounds in MODE 2!), so, e.g...

The nice thing about Pacland is that the background graphics look extremely compressible! Looking on YouTube, the C64 looks very doable (it doesn't even look like it's scrolling at particularly fine amounts). The CPC version sucks! The arcade version has two layers of scrolling, so let's not bother ...

Indeed. On jsbeeb it's not a special case: we handle this by just performing the irq check before ticking the VIA prior to its read/write. In case you're wondering, here's what gets generated for LDA abs in jsbeeb: cpu.polltime(3); cpu.checkInt(); var addr = cpu.getw() | 0; cpu.polltimeAddr(1, addr...

Hey Chris, Great to have another pair of eyes looking critically over this stuff! Assuming this analysis is correct, it could explain the jarring discrepancy between row 6 and row 28 -- it seems suspicious that they'd behave differently. Yeah, I noticed that the results for rows 6 and 7 were likely ...

This program came from trying to make full sense of Kevin Edwards' Nightshade protection which routinely does mad things like ROL &FE65, and also enables a custom IRQ routine. Essentially it sets a timer countdown period of 4, and then contrives to execute various instructions which would acknowledg...

Thank you Ed! Results are consistent with the original run, so I didn't screw up. So the VIA doesn't acknowledge the IRQ if a load/store happens in the same cycle that it's generated. We can probably theorise all sorts of reasons why this might be the case, but as far as emulating it goes, it's a cl...

Updated the timing chart , assuming that the extra tests have worked OK. Looks like writing T1CH also doesn't acknowledge the IRQ right after it's generated (will need to correct jsbeeb), so at least it's kind of symmetrical in terms of unexpected behaviour! Will take a look through those Master res...

Also, it's interesting to see how different the results are on a Master. I'd certainly expected a difference, e.g. because the RMW opcodes perform two reads instead of two writes, and because IRQ entry time is slightly longer on a Master due to JMP (ind) having an extra cycle, but it's also possible...

Wow, fast turnaround Ed, thanks a million!

I just spotted a potential bug which might cause the last values to be overwritten. Would you mind trying this version to see if the last four results are different please?
Sorry 'bout that.

I've updated the test program to check whether writing T1CH right after the IRQ acknowledges it or not.

Would somebody with a real BBC B be able to try this sometime and post the output? Would be much appreciated!

Disk image + plaintext BASIC program in the zip:

Oh for sure. There's another test case in the ssd I posted, that writes 20 to T1 and then gets 20 back under b-em if you read T1CL with LDA (),y. This is because polltime(5) is after all the memory reads for that opcode. Maybe only the ones that need to be correct for Kevin Edwards protection are a...

I'm having a hard time conceptualizing the cycle boundaries, though. Is the dotted line in between the two T1CL 255 values the IRQ? Does that represent action at the half-cycle of the 1Mhz 6522 VIA? Yes, exactly. The dashed line is the point at which the VIA generates an IRQ. I've updated the table...

When I was investigating this, I did run into that case, but it wasn't especially unexpected. That's what happens if (for example): The timer times out and generates an IRQ The 6502 commits to taking the interrupt instead of the next opcode (on the penultimate cycle of an instruction) The final inst...

Having a quick look at B-Em, I see it's already a bit haphazard as to which instructions are implemented accurately and which are not. For example, LDA #imm correctly checks for interrupts at the penultimate cycle, but LDA abs doesn't. If the timer read were to be moved to before the timer tick as y...

What a stunning effort Kieran! Amazing to see that running on a Beeb that smoothly! I'd definitely go with a bigger draw distance than try to get filled areas working, as I don't really think it adds that much, and I think it'd probably look better in MODE 4 than MODE 5. The hatched sky approach of ...

I may have misremembered on T2; I'll have to check my notes. KE's protections require the correct behaviour so I assume my code above is doing the same thing as Dave's results!

The (value + 1) stuff in B-Em (and, hence also jsbeeb) seems to be to correct the off-by-one error that occurs as a consequence of having to choose an order to tick components which, in reality, happen in parallel. When emulating LDA &FE64, B-Em does a catchup of 4 cycles before performing the read,...

It's that time again! For some reason I am thinking of a horizontal shooter but with a bit of pace and in 16:9 aspect ratio! I would like to do R-Type, but that isn't going to happen! I am tempted to do MODE 2, 1 pixel scrolling (2 mode 1 pixels) with a background as I can't think of any beeb games...

Here's a version which performs a variation on a Fisher-Yates shuffle which leaves the first element alone: REM Allocate this scratch space at the start of the program DIM buffer% 255 ... DEF FNshuffle($buffer%) LOCAL L%,N%,R%,E% L%=LEN($buffer%) IF L%<3:=$buffer% FOR N%=L%-1 TO 2 STEP -1 R%=RND(N%)...

But this does relate back to the issue of the T1 PB7 mode. If the model of the output pin being driven by the timer independent of DDRB is right then for port B one would only read the timer value when the pin is an input as otherwise the bit from ODR B would be returned. It's been ages since I've ...