80x28 1bpp tile mode possible?(For terminal emulator)

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by uze6666 »

CunningFellow wrote:OH - bugger

We have both been forgetting something in out recent code.

Tile rows >1 are not the same as tile row 0

We need to add something to ZH to get them.

We are ONE clock down again.
Ah crap! :?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by CunningFellow »

Uze,

Well with the extra clock gained from the "not MUL 16" we are back to "attribute pixel off by one" but have it working at least.

The sparse attribute thing can still work in 3 or 4 clocks. It could make the foreground colour any of 256, but not touch the background colour.

It will also be computationally expensive to change attributes.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by uze6666 »

How does the space attribute thing works?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by CunningFellow »

Just trying to look at it now.

You have an MSB or LSB set in the VRAM.

If the bit is set, then it pulls the next attribute value from a 255 byte heap of attributes. You can only have 254 attribute changes per screen.

When you are setting an attribute bit - it is expensive. You have traverse the screen and list and move/shuffle to add them in the middle. However ALL simple forms of compression are expensive to add things in the middle really.

So for our 4 free clocks we have

BRCS +.2 ; Skip the DEC if the attribute bit is set
DEC XL ; undo the X+ fro the previous read if the attribute has not changed

LD Rx, X+ ; read the current attribute byte into the colour register and inc X
xxxxx


It will also have the off-by-one-pixel-colour problem for the last pixel.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by CunningFellow »

The reason for doing it the above way

Read the RAM every time and undo the increment on X is because you can't skip the LD as a 2 clock instruction without upsetting timing.

but you CAN do a DEC in one clock and skip it.

It just means the list of sparse attribute changes HAS to start at 256 byte boundary AND it can only be 255 long so XL does not wrap and change XH
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by CunningFellow »

well - actually - you could make it MORE than 255 attribute changes per screen AND speed up the search through the compressed data.

You could break the screen into sections and have up to 255 attribute changes per section.

If you just did it the simplest way you could have up to a maximum of 36 attribute changes PER line with a 1K attribute heap. You just have to break up the lines to make sure that you don't hit a 256 byte boundary mid line.

It's going to be some convoluted code to make sure it all works OK. But that is hard stuff for us to do in the background. User code never needs to see how tricky it is.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by uze6666 »

Ah ok, I get the idea. A limited amount of attributes changes globally. So If I understand you code, if I only want to set the attribute color for vram[10]="attrib color", I still need to set vram[11] =global color? We need to bytes for each color change? Wow, it going to get complex fast. And I worry about the cost in term CPU, just doing a full traversal of vram will take several scanlines. But again there's not much other practical way to do attributes it seems. And attributes should not be used that much anyway. Lee, how do you see this?

Btw, CunningFellow, can you post the latest spreadsheet with the inner loop? I'm wondering where you get the carry from for the

Code: Select all

BRCS +.2 ; Skip the DEC if the attribute bit is set
The mul?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by uze6666 »

Perhaps it's a brain fart since it seems too good to be true, can you find the flaw in the following? I realized that there can be up to 16 ins the main loop. That's 16*2*8 bytes tile. Yeah 256 bytes. With a codetile table set at zero:

Code: Select all

ZL=tile row

--main loop--
out portc, r18
ld ZH,X+

out portc, r19
nop
nop

out portc, r18
nop
nop

out portc, r19
nop
nop

out portc, r18
nop
nop

out portc, r19
ijmp
:shock: :?:
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by CunningFellow »

uze6666 wrote:<SNIP> I worry about the cost in term CPU, just doing a full traversal of vram will take several scanlines. But again there's not much other practical way to do attributes it seems. And attributes should not be used that much anyway.
The scanline does not care how the attributes are layed out. AS LONG as it does not cross a 256 byte boundary in the middle of the scan line. The preamble juts sets where to start at the beginning of the scan line and the pixel out code runs with it.

This means you could break up your 1024 bytes of attribute HEAP into 28 smaller 36 byte hunks. Each scanline could have UP TO 36 attribute changes. Then when you needed to change an attribute you would at max need to traverse 80 bytes of VRAM and move 36 bytes of attribute heap.

Uze. Only problem with only load ZH thing is that the code tiles will be scattered all over FLASH and will collide with the BOOT_LOADER I think. EDIT: No we only have 128 tiles - so the bootloader is safe.

Edit again: No I think it will collide. the PC is 16 bit indexed so the top of 64K is 0x7FFF
Last edited by CunningFellow on Sun Feb 08, 2015 9:23 pm, edited 1 time in total.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: 80x28 1bpp tile mode possible?(For terminal emulator)

Post by uze6666 »

Uze. Only problem with only load ZH thing is that the code tiles will be scattered all over FLASH and will collide with the BOOT_LOADER I think. EDIT: No we only have 128 tiles - so the bootloader is safe.
Awesome! Now what to do with...8 free cycles!?! :ugeek:
Post Reply