The Sentinel (1986)

[DirtyHairy]

Yes, just happenstance really as I inherited the makefile/build from Zack. I don't really know at this stage what other options are sensible/possible.

That depends on the target hardware. On the STM32F4x which is in the UNO / Plus you could use the full Thumb2 instruction set. However, if I understand Zack correctly he wants to use the stm32g0 for standalone boards, and that's M0+ --- and I guess that's why the build process is set up this way.

Using the full Thumb2 set technically allows for higher performance at the expense of some size --- you get more registers that are directly available, and more complex addressing modes.

[Andrew Davie]

Happy to report the latest version(s) are working on hardware once again.
Special thanks, DirtyHairy - well spotted indeed.

[Thomas Jentzsch]

Very impressive. I figure you have to do at least 13 stores per scanline (6x GRPx, 6x PFx, 1x COLUPF), correct? And each is 5 cycles (or does ELF allow something faster here?). That would be 65 cycles already, plus some extra cycles for making the 48 pixel code work. Is my calculation correct so far?

[DirtyHairy]

BTW, I agree with Thomas, this is very impressive, even considering the added firepower of the ARM. One suggestion: what about artificially limiting the high resolution bitmap from the top and bottom, too? This would turn it into a sharp area around the crosshair and might look more natural, like central vs. peripheral vision.

[Andrew Davie]

Very impressive. I figure you have to do at least 13 stores per scanline (6x GRPx, 6x PFx, 1x COLUPF), correct? And each is 5 cycles (or does ELF allow something faster here?). That would be 65 cycles already, plus some extra cycles for making the 48 pixel code work. Is my calculation correct so far?

Yes, essentially. Zack magic.
Here's a basic outline of the left window kernel

Code Select Expand

lda #
sta COLUBK
lda #
sta PF2
lda #
sta GRP1
lda #
sat GRP0
lda #
sta GRP1
stx GRP0
sty GRP1
stx GRP0
lda #
sta PF0
lda #
sta PF1
lda #
sta PF2
nop
ldx #
ldy #
lda #
sta PF0
lda #0
sta.w PF1
lda #
sta GRP0
jmp nextLine
nop


[Andrew Davie]

One suggestion: what about artificially limiting the high resolution bitmap from the top and bottom, too? This would turn it into a sharp area around the crosshair and might look more natural, like central vs. peripheral vision.

Yes, that's possible. Very much game-dependent.

[Andrew Davie]

ZeroPage Homebrew has just done a review/showing of The Sentinel and Elite on their show. It went pretty well - no crashes!  And also, it's amazing to see it running on real hardware.  Start at 18 minutes to see the demo.

A couple of interesting suggestions/ideas came up (well more than a couple). One or two resonated and got me thinking if the following might be possible...

1) somehow use the PlusCart wifi to retrieve (x,y) from a server (continually). Provide the (x,y) with a mobile phone app positioned above your TV screen and looking at where your eyes are looking. Wondering if this would be possible at all. If you could track where you're looking and feed that back to the game, then the high-resolution window could be positioned at what you're looking at. That would be cool/interesting. Essentially the only way you could see the "lores stuff" would be to catch it out of the corner of your eye. As soon as it caught your attention and looked at it - it's hires.

2) Automatically position the hires window on items of interest, rather than where the cursor is. Assume in Elite, for example, there's an attack ship zooming around. Focus hires on that, as it moves.


PS: Zack will hopefully have a 2D demo of using the display engine in a showable form sometime in the near future. That will also be super-interesting and shown on ZPH.

[Thomas Jentzsch]

I think it might be feasible move the high resolution bitmap smoothly. I did that for Coke Zero (without PF of course), using three kernels (left, middle, right) which are entered with variable delay. Since a non-reflected playfield doesn't require a very exact timing, it might be possible to still mix the high resolution kernel with the playfield updates. IMO this would be a major improvement for games where the focus is not always centered.

Another idea, where I currently have no clue whether it is possible (and looks good) would be a smooth horizontal transition between the two resolutions. Maybe one could display 40 pixels at high resolution and flicker the remaining 8 pixel left and right of that. Or mix 3 copies close with 3 copies wide.

Besides that, I think following DirtyHairy's idea, but with a smooth vertical transition, might be another option.

Or everything combined. Just dreaming.

[Andrew Davie]

I think it might be feasible move the high resolution bitmap smoothly.

A smooth-moving 6-sprite routine -- I had one running in about 2003 with my mario demos; the large mario scrolled left/right over the entire width of the screen. I copied the code from, I think, Eckhard - but this is taxing my memory of 20+ years ago.

The trick is of course to include the PF updates.  Zack is, I think, working on this.

... would be a smooth horizontal transition between the two resolutions. Maybe one could display 40 pixels at high resolution and flicker the remaining 8 pixel left and right of that. Or mix 3 copies close with 3 copies wide.

I'm really keen to avoid flicker if at all possible. I just understood what you're suggesting - alternating left/right 8-pixel transitions. This is going to flicker terribly - I'm just not inclined to even try that one at this stage; I don't believe it would work.

[Thomas Jentzsch]

The trick is of course to include the PF updates.  Zack is, I think, working on this.

Go Zack, go!

I'm really keen to avoid flicker if at all possible. I just understood what you're suggesting - alternating left/right 8-pixel transitions. This is going to flicker terribly - I'm just not inclined to even try that one at this stage; I don't believe it would work.

Yea, I figured this might not work well. Double size players left and right would be best, but that would require extra cycles plus very precise timing. Most likely impossible.

[DirtyHairy]

Most likely impossible.

Remember this scheme can do bus stuffing, so you can do one write every 3 cycles. Also, the kernel is generated in C on the fly, so you don't need any branches or logic on the 6507 --- your kernel can be nothing but 25 TIA writes and a NOP 😛 In theory, anything is possible as long as it fits those constraints.

[Andrew Davie]

[Thomas Jentzsch]

Most likely impossible.

Remember this scheme can do bus stuffing, so you can do one write every 3 cycles. Also, the kernel is generated in C on the fly, so you don't need any branches or logic on the 6507 --- your kernel can be nothing but 25 TIA writes and a NOP 😛 In theory, anything is possible as long as it fits those constraints.

I thought it would be 5 cycles per store, no?

[DirtyHairy]

Most likely impossible.

Remember this scheme can do bus stuffing, so you can do one write every 3 cycles. Also, the kernel is generated in C on the fly, so you don't need any branches or logic on the 6507 --- your kernel can be nothing but 25 TIA writes and a NOP 😛 In theory, anything is possible as long as it fits those constraints.

I thought it would be 5 cycles per store, no?

No, ELF can also do bus stuffing, so the 6507 gets a stream of "STA ZP", and the cartridge overrides the bus on write -- 3 cycles per stuff. On start, the cartridge briefly displays a test image to check which bits can be stuffed high, and which bits can be stuffed low, and this is used to load A and drive the bus correctly.

[Thomas Jentzsch]

Ok, then a lot more seems possible. Without unrolling, that would be 24 TIA writes a (plus the loop jmp). That actually might allow for NUSIZ writes. Though with 8 pixel sprite intervals, the correct timing might still be impossible.