New version of Scramble for the beeb Finished

[tricky]

Latest version in https://www.stardot.org.uk/forums/viewt ... 73#p410173.

I have had another play with my level converter for scramble and knocked up some code to display the scrolling map (simplified version).
In the screenshot and while running, you can see a yellow bar, this is how long it takes to draw the land.
There is also a bouncing blue bar, one frame it shows the end of decoding a screen's worth of map and the next three, it shows the end of swapping the tile sets to draw the other three offsets of mode 1 pixels in a byte. It should be easy enough to double buffer the drawing code and split the decode over four frames.

Code: Select all

Memory usage (bytes):
1>tiles 1,016
1>land  3,871
1>drawing 943
1>decode  265
1>advance  45

There are still some glitches moving from one map to the next (not to mention the crash at the end) and I might need to tweak the map generation, but it is looking pretty promising at the moment.
I may tweak the sprites to make them compatible with a similar method of drawing, which should leave enough time for the rest of the game.
I might need to get creative with timing all the movement, although as there is no clear phase, the biggest glitch should be one pixel wide!

Anyway, as usual, no promises but it does look feasible

[Pablos544]

Looks great tricky I was hoping your creative talents would turn somewhere good soon. Scramble was one of my two, three, maybe four all time greatest games at the arcade

[tricky]

Although I have always liked scramble and occasionally have a couple of games, I'm not sure what the appeal is once you can loop it a few times.
I'm hoping to be able to add in a few features of the latter variants to mix it up a bit on each loop.

[Dethmunk]

Wow, is this gonna be another 60fps, arcade perfect conversion Tricky?! DO IT!!

[tricky]

Well, maybe 50
I'm not 100% that the timing is possible without some compromises, but it looks like I'm going to give it a go.

[richardtoohey]

Will be watching this one with interest.

Loved Rocket Raid BITD even though (as usual with games) I was never very good at it.

Colourful & noisy & sped along (but a bit flickery.)

[tricky]

I think it Scrolls at 4X the arcade, give our take the 50/60hz.

[tricky]

I haven't touched the code, but have generated the data for the rockets, fuel etc, but not for anything that moves.

Code: Select all

tiles   1008 bytes that make up the level
land    3882 bytes maps of each level
drawing  983 bytes mostly self modifying unrolled loops
advance  258 bytes level across screen (not including sprites)
sprites 1912 bytes stationary rockets, fuel, mystery, KONAMI and the boss.
spawns   548 bytes where the sprites are on the map.

So, about 8.5K for most of the big stuff unless I have missed something and 16K for the display.
Still need the player, firing rockets, saucers, fireballs and explosions ...

[tricky]

I had a go at adding the sprites this morning and this is what I have. I still need to add the boss and KONAMI.

The four lines at the bottom are temporary timing lines:
Yellow: start of drawing.
Cyan: end of land drawing/start of sprite drawing.
Magenta: end of sprite drawing/start of display code update.
Yellow: end of display code update. This has three incremental frames and then a long update frame, which is why it jumps about.

URL:http://youtu.be/nMgHZjkSvJM View at 1080p for 50hz.
EDIT: Attached is a .ssd with the demo on it.
EDIT: Current memory.

Code: Select all

tiles_data  1,008
sprite_data 1,912
spawn_data    546
land_data   3,860
land_draw     829
sprite_code   763
land_code     415

[RobC]

This is looking really good.

I tried to write something similar on the A3000 BITD but this looks much better

Out of interest, how do you draw the lines that mark the time taken for each block of work? I'm used to changing the background colour by palette switching but this looks much neater.

[tricky]

It is just changing the background colour, but I think this version of beebem doesn't update the palette as frequently as b-en, plus I wait half a scanline before going back to black.

[RobC]

It is just changing the background colour, but I think this version of beebem doesn't update the palette as frequently as b-en, plus I wait half a scanline before going back to black.

Ah - thanks, that makes sense. It's a neat effect.

[kieranhj]

Looks nice and smooth Tricky, great work as always! Just so I’m clear what you’re doing here - this is 1 pixel scrolling in MODE 1 by pre-calculating all of the tile offsets in the sequence in which they appear across all of the maps? Then presumably redrawing all of the background tiles each frame albeit on a byte / character boundary for the software scroll? Guessing the background tiles are self-erasing as well?

Still seems like there’s a lot to plot per frame later on when the background is top & bottom of the screen, or am I missing something? What’s the resolution you’re using?

Looking forward to seeing the player and enemy sprites in there.

[tricky]

You have it correct.
The plan is to use 224x256 to match the arcade.
I think that there is enough time to avoid flicker. The trick is to setup (no matter how slowly) the drawing so as to minimise the actual update time.
The longest setup is about half a frame, but this allows the top and bottom land to be drawn in about 1/6th of a frame, instead of the other way around.

[tricky]

I'm a bit stuck / my 6845 foo is failing me

I am trying to have the screen setup similar to Frogger, but with half the interrupts.
b-em, beebem and jsbeeb (great 6845 debugging info) all seem to agree that this should work and produce a stable image.
My TV and silly scope (I'm not that good at driving it) can't seem to find the vsync.

Here is what I am trying to do and when:

timing_diagram.png (5.84 KiB) Viewed 15393 times

Near the end of the first visible row, I set R12/13 for the next, and then immediately after (after they have been read by the CRTC) I latch the values for the third row. This repeats in pairs of rows until just after setting the values at the beginning of the last displayed row, where I change the number of displayed lines to 12 (R4=11). At the beginning of each interrupt, I set rows per "frame" to 1 (R4=0), it only needs to be set on the first line, but it would make the interrupts longer to test each time. I could change the timing for the first one, but thought I would keep it simple to start.

I have checked the timing of the interrupts, setting only R12/13 and changing the background colour.
If the timing was off, the picture would break up with the CRTC shenanigans enabled, but it is fine, it just rolls crazily.

I have trimmed a few rows to give me a little more memory, if I don't need it, I can put things back to match the arcade (224x256).

[Rich Talbot-Watkins]

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?

[tricky]

Sorry Rich, i was hoping you would come to the rescue but I must be missing something.
There are 28 visible with the last line being the first of the last frame's 12 lines (27+12=39).
I'm missing something with the 26+24=39!

[Rich Talbot-Watkins]

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.

[tricky]

I did try a few each way, but they just roll and the scope can't find the vsync.

[Rich Talbot-Watkins]

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.

It seems like there are some strange things we haven't fully understood with the CRTC yet - like I think you or Kieran mentioned something weird about the R12/R13 not taking effect if set right at the end of a CRTC frame. Maybe there are strange race conditions when setting any registers at the end of a frame... this probably needs to be tested in lab conditions! At the end of a line, and particularly at the end of a row, and even more at the end of a frame, the CRTC does a load of stuff, and maybe writes are getting lost in all the madness.

Have you tried interrupting earlier, and adding extra NOPs to allow the next CRTC cycle to begin, before setting the next cycle's registers - basically not cutting things so fine, in case there's a timing-sensitive thing? Remember CRTC writes are at 1MHz, in case that makes any difference to anything!

[ctr]

Comparing it to frogger you've changed the horizontal sync width from 8 to 9 (R3 from &28 to &29). Is that a typo?

[tricky]

I was fully setting the background colour and back between the r12/13 sets, so it wasn't tight at all.
I tried a few selections for sync pulse widths in case that was the problem.
Everything should be the same as frogger at the end of the frame, just less updates during the frame.
I'll check if frogger is doing anything extra on the last interrupt and exactly where it is.
On the scope, it just looks like vsync never happens, but I don't have much experience using it. It locks on immediately to a normal signal, even with the wrong field duration.
I'm wondering if beeb FPGA might have enough debug info to confirm whether what I think is happening is what is happening..

[sirbod]

I know nothing about the 6845 I'm afraid being a VIDC man, but the issue you describe is symptomatic of the VSync pulse being too short, or occurring too late in the frame.

If you're using the same parameters as Frogger and it works there, could it be borderline and the timing around when you set VSync an issue? You mention you've already tried altering the VSync pulse width, so it must be late somehow.

[hoglet]

On the scope, it just looks like vsync never happens, but I don't have much experience using it. It locks on immediately to a normal signal, even with the wrong field duration.
I'm wondering if beeb FPGA might have enough debug info to confirm whether what I think is happening is what is happening..

I can certainly try this on Beeb FPGA, to see if it works or not.

Other ways I can thing to debug this are:
- using ICE T65 to log writes to R04 and R07
- using 6502 Bus Sniffer to log writes to R04 and R07
- iff Beeb FPFA fails in the same way as the real Beeb, we could run a Verilog simulation (this would be hard to setup though)

I'm happy to try to help here.

I did have one theory about what might be going wrong. For most of the field, R04 is zero, which I thing will prevent the internal row counter from incrementing. At the end of the visible part, you set R04 to 12, which releases the row counter. But the value you have in R07 (vsync) is 35, which I think is now wrong. What happens if you set R07 to 8? (Sorry if I am completely misunderstanding things here....) (Edit: Doh, just noticed the purple comment in the diagram about setting vsync to 7 so ignore me!)

Dave

[Rich Talbot-Watkins]

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 row. If timing is a bit tight and you have a bit of IRQ latency, maybe it misses it sometimes. That'd mean another subframe of 12 lines, and cause another VSync to be triggered, which would start your screen rolling.

Try interrupting at the scanline before, and padding out the timing with 128 cycles before programming the registers for the next row. If there really is some kind of weird CRTC race condition when writing registers at the end of a frame, that'd hopefully eliminate that possibility.

I have no other ideas I'm afraid.

[hoglet]

I've just tried Scramble.ssd on Beeb FPGA (both Beeb and Master modes) and the problem doesn't seem to occur. You get a stable scramble screen that is scrolling right to left at the rate of one screen every 4 seconds.

But on a real Master and Beeb, the vertical sync is not stable.

Looking on a scope, I am seeing vertical sync pulses. The duration of each pulse is 128us (2 lines). The interval between pulses is alternating between ~6ms and ~74ms, which will be why you scope is struggling to sync. Try playing with the hold off control (if you have one) and setting this to ~10ms.

Specifically, the leading edges of the pulses are at:
- 0.00000ms
- 6.02057ms
- 79.8045ms
- 85.9532ms
- etc

I'm not sure if this helps or not.

Later I can try to use the 6502 Bus Sniffer to track writes to the CRTC, but that may not be until later this afternoon.

Dave

[Rich Talbot-Watkins]

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 will last 128 rows until it wraps around back to 0). Then you get another VSync at row 7 of the current cycle (12 rows after the last one). I can't really figure why the next one would be 144 rows later - maybe the next cycle actually ends up being 128+12 rows (because R4 is back to 11 at that point), but it still doesn't add up.

Anyway, try positioning the interrupt much earlier in the row and see if it makes a difference. If so, you may have discovered some previously unknown CRTC behaviour which will need to be thought about!

[Rich Talbot-Watkins]

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 imply that, for some 6845s, you could set R12/R13 at different scanlines within the first character row of a new frame and get a change of address midway through a row. Doesn't it? Not that this is related to your problem, but it's probably worth considering all the same, if it's true.

[tricky]

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.
Hoglet, thanks, my scope is a cheap USB only thing, but has been useful.
I'm reassured that it works on beebfpga, as I suspect that does the correct thing regardless of when registers are written.
I don't think that I have come across a 6845 that allowed mid-row R12/13 updates, as I think it would make Frogger look very strange.
I think this may be some 6845 internal timing issue as Frogger reprograms two palette entries, so is likely to be further from the EOL/F.
I will try making the first interrupt earlier or even just adding another that only sets the rows per frame.
I wonder if the visual 6502 guys have done any 6845s yet.

[Rich Talbot-Watkins]

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 carry on with the frame, because the last time it 'looked', R4 was 11. We have no idea about the implementation, but maybe it latches the result of 'have we reached the end of frame' at the beginning of the last scanline of the row, instead of at the end (because perhaps there'd be race conditions otherwise).*

I don't think that I have come across a 6845 that allowed mid-row R12/13 updates, as I think it would make Frogger look very strange.
I think this may be some 6845 internal timing issue as Frogger reprograms two palette entries, so is likely to be further from the EOL/F.
I will try making the first interrupt earlier or even just adding another that only sets the rows per frame.
I wonder if the visual 6502 guys have done any 6845s yet.

From what I can best understand from that document, he seems to be saying that mid-row R12/13 updates only happen on Type 1 CRTCs in the first row of a new frame; after that, it reloads the address from scanline 0 of a character row for each subsequent scanline in that row, as normal.

It'd be really nice to measure all these strange effects with real hardware if anyone had the time and inclination. And also to determine if all Beebs have the same 6845 version or whether different types were used.

* Note that this wouldn't be possible if R9 held the actual number of scanlines, instead of the number of scanlines minus 1, because the 6845 only has logic which can check for equality between values. Not that this implies that it must be true either.