Tempest is possible

[CunningFellow]

The Magic

First up here is my working-out speadsheet for the new video mode. Hope it explains itself in terms of code, but it probably begs lots of questions about where those IJUMPs end up

The overview of the code in a spreadsheet

TempestVidModeODS1.png (18.31 KiB) Viewed 7793 times

The second spreadsheet snippit is showing how I work out where each of the 512 IJUMPs is going to end up. Columns W,X and Y are set to 0/1/0 for the first 256 rows and are set to 0/0/0 for the second 256 rows. Columns AK,AL and AM are the interesting ones. They are

The address each IJUMP will hit.
The end address of the bit of code.
The PixelByte / Phase for this IJUMP.

Doing the MOV/ANDI/ORI in formulas

TempestVidModeODS2.png (11.88 KiB) Viewed 7790 times

If I cut and paste those 3 columns by 512 rows into another sheet and sort on "Jump Address" I can then add a formula in another column that shows me how many words there are between the end of one code-snippit and the start of the next.

Checking for address clashes in a spreadsheet

TempestVidModeODS3.png (6.32 KiB) Viewed 7789 times

Negative numbers are bad. That would mean an IJUMP is landing right in the middle of another piece of code.

I did the exersize twice. Once with the ORI being 0x40 (left side) and once with it being 0x20 (right side). The pivot tables below each show the distribution of the "space" between each "start" and "end".

The -24603 and - 16411 are OK. They are the last number.

Pivot table on the right shows a -27. That is bad. If you search for that -27 you see that PhaseB:0x00 IJUMPS straight into the middle of PHASE-A:0xFF. Not nothing you can do about that.

Pivot table on the left shows no bad -ve numbers. Just a gap of 8165 bytes in the middle that are wasted. I will shoehorn the line draw code into there in the end.

The only last question to be answered is what happens on Phase-A:0x00 and Phase-A:0x01. They jump straight into the middle of the reset/interrupt vectors :O

I have a trick up my sleeve there too

I am so damn tricky.

[uze6666]

Man, you're right, my head hurts! You are really into it, no doubt about it. This seems by far the most ambitious and complex mode made on the Uzebox! ...if not in any 8-bit console!

[D3thAdd3r]

Very cool, now I am sure that your forum name is accurate

[CunningFellow]

Back to Tempest.

Next task is to read a 1Bpp BMP (like) file from the SD card for the back grounds.

I studied the video player demo enough to see that in its inner loop every pixel was read as a byte of the SD card with the following sequence

Code: Select all

IN     Rn, SPDR     ; Read byte from SD card
OUT  SPDR, Rm    ; Que next byte from SD card

And the description of Mode-7 here http://uzebox.org/wiki/index.php?title=Video_Mode_7 explains that every 512 bytes you have to read 2x extra bytes that are a checksum.

The BMP for Tempest is 1Bpp and 256 pixels accross. This means that each line is 32 bytes from the SD card and I must read the checksum every 16 lines.

Each byte has 40 clock cycles to arrive so should be well within spec for most SD cards. I can only envisage problems if the SD card has a long pause when crossing flash page boundaries.

What I have no idea about is how to

1, Set up the file on the SD card so the BMP data is contiguous
2, Set up the UZE hardware so it can read the file off the FAT file system

[uze6666]

I can only envisage problems if the SD card has a long pause when crossing flash page boundaries.

What I have no idea about is how to

1, Set up the file on the SD card so the BMP data is contiguous
2, Set up the UZE hardware so it can read the file off the FAT file system

From experience with the video player, I can't recall is there was a pause between contiguous sectors sectors when using the continuous read command. On Lexar and Kinston brands there was none. Would have to read the spec to be sure.

The only way to be sure the BMP is contiguous is that the card has to be reformatted first.

The movie player demo has the best example on how to find the file and start streaming from it's first sector. I can help on this, if you have specific questions. I'll check tomorrow if I can setup a simple example project.

[CunningFellow]

As far as you know there is no penalty for rewinding and reading the same 13 sectors over and over again is there ?

[CunningFellow]

OK - have gone back and looked at other parts of the mode7 demo than just the render loop.

It does not look that hard, but I am still not 100% certain about it.

One thing I am certain about, I can't go any further till I have physical hardware as the emulator wont read SD card.

I shall have to get out gEDA and draw some lines. May be a few day pause. May be a few month. Depends on health holds up. I am doing very well right at the moment so fingers crossed.

[CunningFellow]

Today I revisited this to try work out how I was going to make the 12000+ lines of code to make it work and realised my little explain at the top of this page has an error.

I was calculating the jump address as bytes rather than words.

The

ANDI should be 0x0F rather than 0x1F
ORI should be 0x20 rather than 0x40

and all the addresses should be divided by ~2

Apart from that everything still stands and tempest shall be making slow progress.

[CunningFellow]

My new pixel render loop for testing. It simply draws 8 different coloured stripes on the screen.

Code: Select all

1:
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 0
	ldi r17, 0b10000000
	nop
	nop
	nop
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 1
	ldi r17, 0b01000000
	nop
	nop
	nop
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 2
	ldi r17, 0b00100000
	nop
	nop
	nop
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 3
	ldi r17, 0b0001000
	nop
	nop
	nop
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 4
	ldi r17, 0b00001000
	nop
	nop
	nop
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 5
	ldi r17, 0b00000100
	nop
	nop
	nop
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 6
	ldi r17, 0b00000010
	nop
	nop
	nop
	out _SFR_IO_ADDR(DATA_PORT),r17	; Pixel 7
	ldi r17, 0b00000001
	nop
	rjmp 1b							; Go back and do next 8 pixels

Notice the lack of decrementing and conditional branching.

Works quite well

I also have worked out how I can do any colour web with no penalty (I think).

[CunningFellow]

Whats is this about in mode6.s

what is this about

uze_audio_out_q.png (9.11 KiB) Viewed 7529 times

And can I use those 213 cycles or are they used some other way for audio mixing?