Expanding Elite

[simulant]

Hi guys, not sure if I'm allowed to advertise in this thread, but as it seems relevant (and for those who haven't seen yet), Pixel Addict magazine have the original Elite game and history as the cover story this month!  https://www.addict.media

[Fessor]

Completion is nearing, almost all graphics functions have been revised and the offscreen buffer is no longer used.

Somewhere, when changing the drawing routines for line drawing, an error must have crept in.

At some point, in flight mode, something is overwritten at some point, which causes the code to miscalculate the vectors. I suspect that some range check doesn't seem to be working when converting to screenmem addresses.

An object is flattened at exactly this angle of rotation, every 90 degrees; but only after you have undocked. In the intro screens immediately after starting the program, everything is OK...
If you dock at the station again, the ship is suddenly equipped with an ECM system, which means that some address calculation is going wrong and is overwriting code and data areas.

I hate this type of error...You cannot view this attachment.

[ervin]

That's excellent progress.
Shame about the bug... those sort of bugs are a pain to solve.

Just wondering, what dev environment are you using?
I really like the look of the assembly window.

[Fessor]

That's excellent progress.
Shame about the bug... those sort of bugs are a pain to solve.

Just wondering, what dev environment are you using?
I really like the look of the assembly window.

Im on Kubuntu 22.04, using VSCode as Editor, my QNAP with GiTEA for self-hosting Git-Repositorys, RASM 2.2.5 as Assembler and switched recently to ACE-DL as Emulator (which Trace-Window is shown) as WinApe began to behave strangely. I love the ability of ACE-DL (via its Albireo-Emulation) and WinAPE (CPCDOS) to access the Filesystem of the host as Drive. This saves me the step of always having to remount a disk image and you can quickly assemble a new version and simply start it in the emulator, which speeds up development enormously.

[ervin]

Nice, thanks for the info!
I'll have to give that a shot at some point.

[zhulien]

Going through some of the code, is it extremely complex or well layed out?  Does it suffer from being on a Z80 vs on the original 6502 (if you have looked)?  Some nice features of the BBC one are missing in the CPC version - and I always wondered why, like the fact that spheres look like spheres in the BBC version.

[Fessor]

The code seems to me to be quite modular, complex, but modular. Some functions are divided into different memory areas so that they can be replaced by other functions at runtime. But on the whole it is quite modular. Since, according to the interview, they reprogrammed Elite for the Z80 from scratch, I don't know how it could suffer from the fact that the original runs on the 6502. But maybe i dont understand this question. 

Since, as far as I know, the very first Elite version was squeezed into 32k on the BBC, with a reduced shipset, you can say that the ZX version is almost identical in content. According to the interview, they would have liked to do more, but they ran out of time. They probably also ran out of memory to be able to fit more in. But this was the Basis they auctioned the porting Rights of.
So You can't/shouldn't compare the BBC's extended disc version with the one for the Spectrum and the CPC. That came later with the Port for the C64.

The spheres on the BBC may have been a nice gimmick at first, if that's what you meant, but I'm glad they didn't have recreated that on the z80s. The planets rotate way too fast and the axis and plane of rotation doesn't have much to do with science. I mean, even if you don't have orbital mechanics, these effects destroy the last illusion of it - for me at least

https://archive.org/details/amtix-magazine-13/page/n83/mode/2up?view=theater
https://www.ricardopinto.com/2022/09/19/interview-about-elite-z80-conversions/

[Fessor]

So, I found the bug that caused the distorted display. In the invisible area of the image memory, the value tables for square numbers are stored at 0x5600-0x57ff. The address lines are deleted backwards using a PUSH loop, including the area from 0x5c00 - 0x5800.

Anyone who knows the organization of the screen RAM will probably see what the story is leading to if the screen RAM is in bank 1. The individual lines start at addresses 0x4000, 0x4800, 0x5000, 0x5800...


Now there is the interrupt routine in which the color split and a few other things are done, in which a few calls to subroutines are also made. Calls are known to store return addresses on the stack.

Unfortunately, an interrupt can occur while the deletion of an image line has just been completed, i.e. it has reached the beginning of a line address, 0x5800, directly after the last PUSH, and overwrites the last two table entries of the square numbers when storing the return address of a call at 0x57fe and 0x57ff.

This means that the math routines occasionally use two incorrect values for its calculations leading to malformed objects like the flattened space station.

[Fessor]

I think, they had also this Problem.
Found hidden in a PUSH-Loop for circle-drawing to screenmemory this snippet:

Code Select Expand

    LD     IX,0x0
    ADD    IX,SP        ; ix = sp
    LD     SP,ce2func57
    LD     (IX-0x1),D
    LD     (IX-0x2),E
Instead of doing 64 PUSHes they are doing 63 and then use IX for the last two bytes to put to Screenmemory and have set up a separate stack address for this possible case where the interrupt then can safely store a return address

[ervin]

This is remarkable.
I wouldn't even know where to start trying to disassemble and understand a full (and complex) game like this.

[Fessor]

This is remarkable.
I wouldn't even know where to start trying to disassemble and understand a full (and complex) game like this.

With the right tools, a lot of persistence and willingness to experiment, it's not that difficult. Of course, you also have to know about the system architecture to be able to recognize whether something like 0xc000 in ld hl,0xc000 can simply be a variable or a memory reference.

For Bruce Lee and Elite I used Ghidra, for possible future things I want to take a look at https://www.cpcwiki.eu/forum/programming/any-interest-in-a-cpc-reverse-engineering-tool/. It looks pretty promising and also has nice instructional videos.

[Fessor]

Double buffering works so far, but the dashboard's drawing strategy is giving me a headache.
In principle, drawing only takes place when values change in order to save computing time. With double buffering, unfortunately, this only updates the graphics in one of the banks.
I want to avoid having to draw in both buffers when updates are pending on the dashboard in order to keep this part identical in both buffers.

I had now thought of always having drawing operations in the dashboard carried out in bank 1 and also carrying out an address change in the interrupt when the color change is made.

At the first interrupt, when vsync occurs, I toggle the display address via R12/R13 between 0x4000 and 0xc000.
At the 4th interrupt, when the colors are switched, I also want to change the address of the displayed area via R12/R13 to stay fixed at 0x4000. But changing the address alone obviously doesn't seem to be enough.

I could use a little help with how rupture works.

Code Select Expand

doColorSplit
    LD     B,0xf5                   ; Address PPI Port B
    IN     A,(C)                    ; read PPI
    AND    0x1                      ; mask bit 0 for vsync
    JR     NZ,setViewportInks       ; bit set = vsync occoured, set colors for viewport, toggle screenmem R12/R13 between 0x4000/0xc000, reset counter
    LD     A,(IRZonecounter)        ; "normal" 300hz interrupt occured
    INC    A                        ; count up how many interrupts occured
    LD     (IRZonecounter),A
    CP     0x2
    JP     C,IRonZone1              ; counter = 1
    JP     Z,IRonZone2              ; counter = 2
    CP     0x4
    JP     C,IRSound                ; counter = 3 - SFX-Player, Keyboard-Scanning
    JP     Z,setDashboardColor      ; counter = 4 - colorchange for Dashboard, set R12/R13 to Addr 0x4000
    JP     IRSetInk1                ; last interrupt of frame

You cannot view this attachment.

[Mark_wllms]

Since you are doing the rupture anyway, why not draw the view in hi-res mode 2 and the dashboard in mode 1?
Can't be that hard...

[Fessor]

Since you are doing the rupture anyway, why not draw the view in hi-res mode 2 and the dashboard in mode 1?
Can't be that hard...

Since the colors of the CPC version give it more atmosphere and depth, nope, no Mode 2. Mode 2 would not speed up the drawing operations either.
For the scanner, I prefer the precision of Mode 1 to the low-res versions of the BBC/C64.

I have to find out how rupture works first anyway.

[andycadley]

Rupture is a lot more complex than that, basically the CRTC will only reload the address registers at the start of a frame. So you have to trigger a VSYNC part way through the display, but make the pulse too short for the monitor to respect it. And then create a second frame that ends up occupying the remainder of the "real" frame. And naturally the are a bunch of quirks to retain compatibility between different CRTC types.

[zhulien]

What would be involved to add a 3d option for anaglyph glasses or 3dtv (2 side by side images). The latter with some 3d TVs when you switch to 3d mode, if the 2 sides are correct aligned will work correctly with polarized glasses.

[Fessor]

What would be involved to add a 3d option for anaglyph glasses or 3dtv (2 side by side images). The latter with some 3d TVs when you switch to 3d mode, if the 2 sides are correct aligned will work correctly with polarized glasses.

Since I haven't yet understood the math routines and haven't identified their functions...
I would say a complete overhaul is needed to calculate and draw these perspective angle offsets.
I think that this would reduce the frame rate too much, especially since the space dust is drawn pseudo-3D. In any case, it's not something *I* could do, since, as mentioned, I have neither identified nor understood the math routines.

[zhulien]

What would be involved to add a 3d option for anaglyph glasses or 3dtv (2 side by side images). The latter with some 3d TVs when you switch to 3d mode, if the 2 sides are correct aligned will work correctly with polarized glasses.

Since I haven't yet understood the math routines and haven't identified their functions...
I would say a complete overhaul is needed to calculate and draw these perspective angle offsets.
I think that this would reduce the frame rate too much, especially since the space dust is drawn pseudo-3D. In any case, it's not something *I* could do, since, as mentioned, I have neither identified nor understood the math routines.

Yes, you would be rendering 2 images for every frame. Half frame rate if its already full tilt. 

[Mark_wllms]

What would be involved to add a 3d option for anaglyph glasses or 3dtv (2 side by side images). The latter with some 3d TVs when you switch to 3d mode, if the 2 sides are correct aligned will work correctly with polarized glasses.

I think that this would reduce the frame rate too much, especially since the space dust is drawn pseudo-3D. In any case, it's not something *I* could do, since, as mentioned, I have neither identified nor understood the math routines.

The space dust could be the same in both left and right frames, as it is in the distance - I think it's meant to be a star field.