Uzebox Forums

OK, tell if it works or if you run in something which looks like an error on my part. Then if you feel it necessary, other elements might be added to the mode.

Palette manipulation is one thing definitely possible. It should be obvious that you can change the palette of the entire frame (so for example you can get a true fade, or turn your charset to appear monochrome), what I mean is that it is rather simple to add features which manipulate the palette within the frame, line by line or tile row by tile row. For example replacing a single color index (224 bytes of RAM) on every line can give you rasterbars (it is possible to make this feature so it can be turned on/off to free the associated RAM when not needed). Another idea may be having more than one 16 color palettes in either ROM or RAM (there is room in the HSync to reload it), selectable on each tile row (this could be useful for having status lines with different color set than the main playfield, or to have palette manipulation on the main playfield without making the status lines invisible or unreadable).

If you wish to have RAM tiles, that should also be possible by specialized row code. I made the structure of the mode so it is even possible to reuse the scanline loop to spit out some tiles, I mean that with some limitations it may be possible to have both some RAM tile hackery and ordinary code tiles appearing on the same row. I need to know however what you have on your mind if you wish to have this. By that you mentioned SD streamed content, I assume that you might rather want some kind of framebuffer, which may be easier to get.

What is going on is there are only 32 tiles, but they are repeated. Although the image has 96 images, for some reason they are looping. Such that 0,32, and 64 are all the same image. That's why the rooms are displayed correctly but corridors, and monsters(letters) are not correct.

Could you reproduce this on the example? I tried a 96 tile set with it, but it behaves correctly (no repeats) for me (I tried outputting all tiles to vram directly of this 96 tile set, all are correct).

I went back in, and recreated the tileset.s, which has fixed the problem. I'm not really sure what happened the first time. But at least now it's working well.

By any chance, didn't you try to generate it from a 192 x 24 image originally? (That is, a 32 x 3 array of tiles). That would fail exactly the way you described: the mode is designed to support arbitrary tile height, and so the generator would interpret that image as 32 units of 6 x 24 pixel tiles. Then due to that it inserts an "andi" instruction to mask off unused bits of the tile index, you get repeats (since if you had 32 tiles only, the high 3 bits of the tile index could be ignored, allowing those bits to be used for other purposes). If you used the 6 x 24 pixel tileset with a configuration of 8 pixels tile height, you would see only the top 8 rows of the tiles. You would see this case if you checked the top comment of your generated "tileset.s": for such a set it would read as "Mode 90 tileset of 32 tiles at 24 pixels height".

I don'the lieve so. But it could have happened. I had redid the colors and tile format at the same. Maybe I specified the wrong file. At least it'seems going now. Saved about 20k on file size.

After reading my previous post, I will no longer post from my phone. However I finally got the bugs all fixed I had introduced. Here is what the screen shots look like now.

It looks like really good progress, keep at this one to the end!

Jubation do you think you could add RAM tiles? It would be nice to be able to display some images from an SD card. I understand the fidelity would have to be low. The ram use would obviously be low. I can recreate the screen after the drawings are shown. Maybe with a 16 color palette, to help reduce the RAM usage. I was thinking a 60x60 pixel, 16 color mode, 4color 80x80 mode, dither 120x120(with change per line color capabilities.

Some clarifications are necessary.

The simplest is to do it as an alternate row mode which by some constraints you could mix with the "text" mode. That is, you have one row mode which produces an image from RAM, and another (which you already have) which produces "text".

Since you already have a 16 color palette there, it is the most economic to reuse that. At low horizontal resolution doing 16 colors without a palette buffer is possible.

Some suggestions:

8 cycles / pixel, 4bpp: A row produces 180 pixels from 90 bytes of RAM, 3 pixels / "tile" (at full width).
12 cycles / pixel, 4bpp: A row produces 120 pixels from 60 bytes of RAM, 2 pixels / "tile" (at full width).
24 cycles / pixel, 4bpp: A row produces 60 pixels from 30 bytes of RAM, 1 pixels / "tile" (at full width).
8 cycles / pixel, 2bpp: A row produces 180 pixels from 45 bytes of RAM, 3 pixels / "tile" (at full width).
12 cycles / pixel, 2bpp: A row produces 120 pixels from 30 bytes of RAM, 2 pixels / "tile" (at full width).
24 cycles / pixel, 2bpp: A row produces 60 pixels from 15 bytes of RAM, 1 pixels / "tile" (at full width).

At 8 or 12 cycles width double scanning should be used to get roughly square pixels (8 cy will be a bit tall, 12 cy a bit wide). 24 cycles width would go best with quad scanning. Of course you may go for less than full width (that's how 8 cycles / pixel 4bpp might only be useful).

The "tile" unit of course isn't present, I just mentioned so you see how it aligns with the "text" mode rows. You might also consider that a VRAM row contains 60 bytes in text mode, for example quad scanned 12 cycles / pixel 2bpp uses the same. This would simplify your RAM layout with a mixed screen (giving a 2bpp 120 x 56 pixels alternate mode if you fully used graphics). Otherwise you might use a second bank of VRAM rows to bump your graphics RAM (such as to 120 bytes per tile row).