Tempest is possible
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
The Magic - was Re: Tempest is possible
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 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.
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.
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.
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 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.
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.
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.
Re: Tempest is possible
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!
Re: Tempest is possible
Very cool, now I am sure that your forum name is accurate
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Tempest is possible
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
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
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
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
Re: Tempest is possible
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.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
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.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Tempest is possible
As far as you know there is no penalty for rewinding and reading the same 13 sectors over and over again is there ?
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Tempest is possible
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.
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.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Tempest is possible
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.
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.
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Tempest is possible
My new pixel render loop for testing. It simply draws 8 different coloured stripes on the screen.
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).
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
Works quite well
I also have worked out how I can do any colour web with no penalty (I think).
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Tempest is possible
Whats is this about in mode6.s
And can I use those 213 cycles or are they used some other way for audio mixing?
And can I use those 213 cycles or are they used some other way for audio mixing?