Jump to content
IGNORED

HIP/Visdom2


Schmutzpuppe

Recommended Posts

Emaky -- How is it possible to argue with people who don't know nothing and allways denieing the possible in a negative way

 

Yeah you're right the last 24 years of Atari ownership and work on this platform have taught me nothing - yeah that's right I admit to knowing nothing' date=' and you know everything, well I have nothing constructive to say to that :roll:

 

So long, and thanks for all the fish...[/quote']

 

 

People are allways trying to put shoes on when they fit perfectly.

Link to comment
Share on other sites

I have no idea why this effect would look better on PAL machines. Each line is displayed separately in time' date=' with no regard for the previous line, isn't it? I know SECAM TV's mix lines together (because in SECAM, the vertical color resolution is cut in half and distributed over 2 lines) but I wonder why this effect works on PAL.[/quote']

 

Graham of Oxyron wrote a long and very detailed account of how the C64 handles stuff like this - sadly, he's a genius and i'm not so i can't remember the details, but suffice to say it does make a difference. Off the top of my head though, a PAL C64 has a slightly different pixel aspect ratio to an NTSC machine so if that applies to the Atari as well (you must remember that i've only ever seen a PAL 800XL running) so that should cause the displays to look different for a starter...?

Link to comment
Share on other sites

Right' date=' a standart would be nice but i don't think that this is the way it would work.

The editor has to adapt the code for each scanline.

It's not usefull to have a generall routine that write the values to each register in each scanline.

The job isn't that easy... :([/quote']

 

I agree with this. There will need to be a file format for the editor, but the result should be executable code. There could be 2 ways to do it:

 

1. The user selects a line, and then clicks on the area they want the change to occur at. The changes will be displayed and later turned into code.

 

2. The user edits asm code side by side with the picture and the results are updated in real time.

 

-Bry

Link to comment
Share on other sites

Graham of Oxyron wrote a long and very detailed account of how the C64 handles stuff like this - sadly' date=' he's a genius and i'm not so i can't remember the details, but suffice to say it does make a difference. Off the top of my head though, a PAL C64 has a slightly different pixel aspect ratio to an NTSC machine so if that applies to the Atari as well (you must remember that i've only ever seen a PAL 800XL running) so that should cause the displays to look different for a starter...?[/quote']

 

Here's what I know about NTSC and PAL Atari's

 

On the NTSC Atari, the pixel clock IS the NTSC clock. This is why you can produce artifact colors in the 320 mode (except when using chroma/luma video). Alternating light/dark pixels produce a 3.579MHz wave and confuse the TV into thinking there's color. On PAL, the pixel clock is different from the PAL clock, and no colors occur.

 

I believe NTSC and PAL both have all the information needed for a single line contained in that line (again, SECAM does not and must merge 2 lines to get a complete color signal). PAL alternates the phase of the color signal every line (PAL means Phase Alternating Line), but I don't know why lines would appear mixed. Every line is still a snapshot in time. I need to get a PAL TV and check it out!

 

-Bry

Link to comment
Share on other sites

There are two extremes here. On the far end, you can include with your image a massive block of machine code that is directly executed. This would produce gigantic image files (by A8 standards). On the other end, you can have a list of register changes that are processed in real-time by the kernel. This wouldn't yield nearly the color density of a hardcoded kernel.

 

Instead I suggest an intermediate approach, where a list of register changes is included with the image, and then a hardcoded kernel is generated from this list at load time.

 

The actual data format wouldn't be too terribly complicated:

 

------------------------------------------------

 

IMAGE CHUNK

standard Microillustrator format

 

REGISTER INDEX CHUNK

one-byte indexes to two-byte memory locations

1=704

2=705

etc...

 

INITIALIZATION CHUNK

optional - only runs once

index = data

index = data

index = data

etc...

 

KERNEL CHUNK

hardcoded kernal generated from this

index = data

index = data

index = data

etc...

 

------------------------------------------------

 

So the kernal parser would pull in, for example, a "1" = "0" pair and interpret that as "Store a 0 in memory location 704". The reason for the index chunk is twofold. 1. It shrinks the file size by not requiring the storage of two-byte values. 2. It future-proofs the format. The first version of a generator that used this format might only touch the color registers, but by allowing writes to any memory location, later versions could manipulate any ANTIC/GTIA register.

 

Certain index ranges would have to be reserved. For example:

255 = end of kernel

254 = end of line (WSYNC)

253 = NOP

 

Anyway, that's actually the easy part. The tough part is coming up with an algorithm to generate all this data. Because let's be honest... there's no way for a human make full use of this format. GED has been around for over a decade, and how many pics have you seen for that format?

 

So what would the best algorithm be? Tough question. Since it would be scanline-based, that would simplify color selection somewhat. But since the palette "evolves" horizontally it would have to be a sliding-window routine that broke each line down into overlapping chunks. This would most likely require an iterative approach that tried multiple solutions until arriving at a sufficiently low error. Heck, a genetic algorithm with the best color fit as its target might even work.

Link to comment
Share on other sites

Are you suggesting a format where the Atari generates a kernel before displaying the picture? That's a good idea, but the code to do it may be as big as including a pre-fab kernel.

 

Edit: Although- now I'm guessing that you're thinking of the viewer/picture scenario, where the files are kept small and the viewer gets bigger. I was thinking of the combined size needed to put the images into a game. Even the full kernel could be simply compressed if you limit the instructions to load/store immediate/register instructions.

 

STA $D01F

 

could be reduced from 3 bytes to 1 with most of the bits used for the register id, and a few used for the instruction type.

 

Here are some other issues:

 

There are only so many changes you can make to registers before the scanline starts, but if you don't use WSYNC, you can begin making these changes during the last few visible cycles of the previous line. Obviously there aren't that many cycles on which a change can happen during a line, so the A,X, and Y registers will need to be preloaded with data needed. Any unused cycles should be used to reload these registers. It gets tricky, but a graphical editor of some sort would be a big help.

 

An editor that could do all this could produce some very interesting stuff. An editor smart enough to produce the code just from user requests would be incredible.

 

-Bry

Link to comment
Share on other sites

That's a good idea' date=' but the code to do it may be as big as including a pre-fab kernel.[/quote']

First, why would that matter? The code would be built into the viewer, not each image file.

Second, I think the generator code would be really simple. 99% of it would just be pushing out LDA/STA combos.

 

Actually, now that I think about it the kernel chunk should come first, so display memory could be used as a working cache.

Link to comment
Share on other sites

Here's the instructions you could pack into the bytes:

 

LDA imm

LDX imm

LDY imm

STA reg

STX reg

STY reg

NOP (2 cycles)

NOP (3 cycles - undocumented Op)

 

That would fit in 3 bits (unless I forgot something) and leave 5 bits for 32 possible registers. Of course, the Load instructions would have to be followed by a byte (leaving the extra 5 bits free - maybe the immediate data could be partially stored in there, and partially in extra aux bytes).

 

-Bry

Link to comment
Share on other sites

I don't think it's a good idea to even consider dragging the X/Y registers in at this point.

 

Imagine how complicated it would be to come up with an algorithm which made effective color choices at fixed intervals across the screen.

 

Now imagine how much MORE complicated it would be if it had to deal with non-fixed intervals and register/cycle pools.

 

Baby steps, eh?

 

 

EDIT-- And I'm not sure what you mean by "Load instructions would have to be followed by a byte". There are no load instructions in the format I suggested. There are no store instructions. There are simply index/value pairs which are interpreted into LDA/STA commands at load time.

Link to comment
Share on other sites

And I'm not sure what you mean by "Load instructions would have to be followed by a byte". There are no load instructions in the format I suggested. There are no store instructions. There are simply index/value pairs which are interpreted into LDA/STA commands at load time.

 

Your proposed standard doesn't seem to include any information about where the changes are to be made, or are you thinking that all the changes are made in the horizontal blank? Mid-scan line changes would somehow have to include some kind of timing information as well, which means that it may be easier to include a fully formed kernal with the picture file itself (you can always compress it for smaller picture size.)

 

I think that using this type of picture in a game (with mid-scan line changes) will have to be "hand coded", unless it is just for a static picture (title, highscore screen)

Link to comment
Share on other sites

...it happens on every pal machine (800xl' date=' c64 etc etc)..[/quote']

 

So' date=' you mean it won't work on NTSC machines:

F.e. TIP-pictures are not possible on NTSC 8bits???[/quote']

 

exactly. this only works on PAL and SECAM machines. on NTSC the color tones of two rasterlines don't mix.

Link to comment
Share on other sites

I believe NTSC and PAL both have all the information needed for a single line contained in that line (again' date=' SECAM does not and must merge 2 lines to get a complete color signal). PAL alternates the phase of the color signal every line (PAL means Phase Alternating Line), but I don't know why lines would appear mixed. Every line is still a snapshot in time. I need to get a PAL TV and check it out![/quote']

 

secam encodes on one line U and on the next V etc, so in one rasterline you either have U or V encoded so you need two lines to get both.

 

ntsc has both encoded in every line, same as pal... the difference is that to decode pal you need two rasterlines.

 

the maths behind the encoding/decoding the pal color carrier is pretty simple:

 

assume you have a sinus wave where amplitude is U and a cosinus wave where the amplitude is V. both waves have 4.43 mhz. now pal encodes this like this:

 

on the even lines C = U*sin + V*cos

on the odd lines C = U*sin - V*cos

 

to tear both waves apart the maths is pretty simple when you assume that the color tone doesn't change too much from one rasterline to the next:

 

U*sin = C(this rasterline) + C(previous rasterline)

V*cos = C(this rasterline) - C(previous rasterline)

 

that addition/subtraction is the reason why two rasterlines mix 50% to 50% in color tone (no luminance is mixed). that mixing appears on all pal devices and i think for 8 bit computers it's a very nice feature since it makes pictures look smoother without blurring the picture (no loss of resolution). also it makes computers like the C64 have far more than 16 colors even though the video chip itself only generates 16.

Link to comment
Share on other sites

why should HIP or TIP not work on NTSC machines?

 

HIP f.e. is based on vertical interlacing as well...

 

http://www.s-direknet.de/homepages/k_nadj/hip.html

http://www.s-direknet.de/homepages/k_nadj/tip.html

 

and TIP is not so much different?

 

so

 

1st vbl

line0 = graphics 9

line1 = graphics 10

2nd vbl

line0 = gr.10

line1 = gr.9

 

so i assume that this works on both tv standards?

Link to comment
Share on other sites

Your proposed standard doesn't seem to include any information about where the changes are to be made

They would be made as fast as possible. Even then that's not as fast as we'd like. The generated code would be a solid stream of LDA/STA/LDA/STA/etc.

 

Sorry, I see how you would do this in your standard: insert NOP "codes" into the picture file to pad out the kernal so that color changes occur in the correct places. That would also allow quite a good compression ratio I would think!

Link to comment
Share on other sites

I don't think it's a good idea to even consider dragging the X/Y registers in at this point.

 

The reason is that STA nn' date=' STY nn, STX nn allows 3 changes in 12 cycles. LDA x, STA nn, LDA x, STA nn, LDA x, STA nn takes much longer, so you preload A,X and Y.

 

Imagine how complicated it would be to come up with an algorithm which made effective color choices at fixed intervals across the screen.

 

Now imagine how much MORE complicated it would be if it had to deal with non-fixed intervals and register/cycle pools.

 

Baby steps, eh?

 

I was really trying to come up with the most optimized method.

 

EDIT-- And I'm not sure what you mean by "Load instructions would have to be followed by a byte". There are no load instructions in the format I suggested. There are no store instructions. There are simply index/value pairs which are interpreted into LDA/STA commands at load time.

 

I was saying that a simple compressed kernel format might be as compact as your table method.

 

-Bry

Link to comment
Share on other sites

May I suggest a routine that is based on NOP Operations from the beginning of the screen until the last displayed color clock.

By changing registers and the needed LDA STA combinations, the program may calculate the usage of the CPU cycles and exchange the code so that allways the same cycle count is given.

 

original:

nop nop nop nop nop =10 cycles

color set:

nop lda sta nop =10 cycles

Undo:

nop nop nop nop nop =10 cycles

 

 

By doing so, the editor can allways exactly calculate the possibility of changings when comparing the cursor position and the available counts. The readable NOP commands will presafe errors by setting the commands and not to partial overwrite code that will make the computer crashing.

Link to comment
Share on other sites

Frohn: So you're saying that PAL actually requires the color info from 2 lines to create each line?

 

NTSC = Independent UV on each line

PAL = Averaged UV from 2 lines

SECAM = U & V from separate lines

 

Doesn't this create a loss of resolution on PAL? Would an NTSC screen be sharper?

 

-Bry

Link to comment
Share on other sites

@ Heaven

 

We are talking about two different types of interlacing. When you say HIP is based on interlacing you mean flickering, that is, mixing colors of 2 consecutive frames.

 

When you make a static TIP picture the colors of consecutive rasterlines are mixed, and that is in fact a totally different kind of interlace (namely without any flickering). So TIP uses two types of interlacing at once.

 

 

@ others

 

NOPs take indeed 2 cycles, but when the screen is being drawed you still have the {first half} - {second half} problem. In the second half every other cycle is stolen by graphics DMA, but a NOP only needs 1 cycle for memory access (Opcode fetch) as it doesn't do anything else with the memory. So the 2nd NOP cycle is executed by the 6502 when Antic uses memory. That's why you can move a register-change exactly 1 gr.0 char- width left or right (when drawing the second half).

 

On the first half (when RAM refresh takes place) you can move a register-change 2 gr.0 char-widths left or right, which gives less flexibility. You can also only change half the amount of registers in the first half, compared to the second half. You have to take great care of this assymetry, when writing an editor.

 

P.s.

 

The undocumented 3cycle NOP will actually take 4 cycles under DMA

in the second half of the screen (right part of a rasterline!) :D, watch this diagram:

 

-D-D-D-D-D-D    :Antic DMA

xxNNNXxxxxxx    :CPU



- = cycle with free memory access for CPU

D = cycle that's stolen by Antic

x = some arbitrary CPU activity

N = Needed CPU cycles for 3cycle NOP: The instruction is read in the first cycle!

X = CPU is halted

 

 

 

 

-----

mux

Link to comment
Share on other sites

The reason is that STA nn' date=' STY nn, STX nn allows 3 changes in 12 cycles. LDA x, STA nn, LDA x, STA nn, LDA x, STA nn takes much longer, so you preload A,X and Y.[/quote']

I'm aware of that. But if you want to do it again then it takes mumble cycles to reload all three registers, during which time NO color changes can occur. TNSTAAFL.

 

Sticking to LDA/STA provides a steady stream of color change zones. This would be much easier to write a general conversion algorithm around than one that had to figure out where to wedge burst write/reload cycles.

Link to comment
Share on other sites

Here's the instructions you could pack into the bytes:

 

LDA imm

LDX imm

LDY imm

STA reg

STX reg

STY reg

NOP (2 cycles)

NOP (3 cycles - undocumented Op)

 

That would fit in 3 bits (unless I forgot something) and leave 5 bits for 32 possible registers. Of course' date=' the Load instructions would have to be followed by a byte (leaving the extra 5 bits free - maybe the immediate data could be partially stored in there, and partially in extra aux bytes).

 

-Bry[/quote']

 

You can pack far more commands with this, if you consider that a NOP command would not need 5 bits of additional information, and a LDA imm command would need 8 bits:

 

Let's do this in binary:

 

1xxyyyyy

 

xx=00 STA at reg $D0-&B000yyyyy

xx=01 STX at reg $D0-&B000yyyyy

xx=02 STY at reg $D0-&B000yyyyy

xx=03 reserved

 

0xxxxxxx

128 other commands, only 5 others needed.

 

For a LDA imm you'll need an additional byte

 

OR...

you can make a palette to choose from 32 colors, so you can define:

 

0xxyyyyy

 

xx=00 LDA imm palette color &B000yyyyy

xx=01 LDX imm palette color &B000yyyyy

xx=02 LDY imm palette color &B000yyyyy

 

-----

mux

Link to comment
Share on other sites

Sticking to LDA/STA provides a steady stream of color change zones. This would be much easier to write a general conversion algorithm around than one that had to figure out where to wedge burst write/reload cycles.

 

When the first half of the rasterline is being drawed the {LDA, LDX, LDY (just before start of line) and STA, STX, STY} solution might work best.

 

In the second half, just use {LDA-STA-LDA-STA ...etc.}.

 

-----

mux

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...