VIC-I anomalies in emulation

[Mike]

I'll implement your program tomorrow and tell the results.

So what are the results?

If it proves impossible to produce the desired 'super' hi-res screen, then we could as well close this topic. In this case VICE needn't be updated, either - except for the cases where the emulation is able to do more than the real hardware, when program such written then fails on the VIC.

Instead we could concentrate on a more realistic goal: The 160x192 resolution works. As I said in your topic about Hires Graphics, I don't favor a pure POKE and SYS extension, as it only replaces some POKEs for other POKEs.

I once used a BASIC extension for a 128x128 bitmap (named: "MINIGRAFIK"), that had the following commands:

@ON: Initialise graphics
@CLR: Clear bitmap (and set colours from address 648)
@RETURN: Back to text mode
@<colour>,<x>,<y>: Set point in <colour> at (<x>,<y>)

note <colour>, <x>, and <y> could be arbitrary expressions. <colour> should evaluate to either 0 (clear) or 1 (set). <x> and <y> from 0 to 127. Finally it even had one function:

@(<x>,<y>): Return colour of (<x>,<y>) (either 0 or 1)

This extension was done in 256 bytes! From what I remember I wrote several programs with it (simple Paint-programs, Pie-Charts, Block-Diagrams, etc.) If you are interested, we could produce a similar extension for the 160x192 resolution, and make this available here in Denial. But at first I'd need to dissect a similar extension - esp. to see how the @() function is implemented. And continue the discussion in the 'Hires Graphics' topic.

Greetings,

Michael

[carlsson]

Sorry, I've forgotten to continue on this exploration.

On the other topic, why not? I believe the line drawing routine takes about half the program size in the hires kit I posted. If you only need to plot individual points, you could as well do it directly from Basic, probably faster than going via a machine code routine. If you want routines to draw lines, circles or flood fill areas, I would suggest developing them in ML, even if you don't have a Basic command extention to handle it.

[carlsson]

An interesting development, probably depending on where in the raster line we make the change:



It appears that the "test" value we're trying to change for every line in reality gets increased only every 16 lines, but at least we get the correct value. It is a bit odd, as I previously managed to unroll two loops with different LDA values and got "action" on every row?

The first row will take 73 cycles to run, but the following lines are 71 cycles each. Not that it matters much, as the first line will only shift the action two cycles to the right.

The 16 lines tall "pixels" was also mentioned in that other document. I experimented a bit by toggling 16 pixel character height in 36867, but no difference. However, I expanded screen height as much as possible:



The LDA #0 pattern is different!

In my program, I sync to raster line 100 and then go. It affects where the broken line appears, but nothing else.

I also changed LDX #155 to #156 to make it roll downwards slowly:


I'm not sure we can get much farther. It appears on some columns we may be able to push any bit pattern, but what is the difference between two unrolled loops and a normal one?

[Mike]

It appears that the "test" value we're trying to change for every line in reality gets increased only every 16 lines,

That means only the high-nibble gets through. The low-nibble (at least in two of the screens) is constantly 1 - exactly the same as the colour! That means there still could be some influence by the colour RAM.

but at least we get the correct value. It is a bit odd, as I previously managed to unroll two loops with different LDA values and got "action" on every row? [...] what is the difference between two unrolled loops and a normal one?

Only their position in RAM could matter. Edit: I re-read this, and thought, that's not the point. You can see the single line of other CPU activity, with the reset to LDA #$00, and the following busy wait.

As last resort you could point $9005 not to the colour RAM ($55), but to the address range $0400-$0FFF, i.e. write $99, $AA, or $BB into $9005 instead. If that doesn't work, well, than that's about it.

Michael

[a1bert]

Hello all. Summing up some things:

Great idea, btw..

VIC-I fetches the video matrix data first, then font data. There are no bad lines, and no internal buffer to hold the video matrix line. Because you are providing the font data from the data bus, the video matrix data does not matter (the matrix address can be anything), the instruction can be anything, as long as it is a two-cycle instruction which performs a read during the second cycle and the timing is correct.

Notice that 65xx always performs bus actions on every cycle, even with two-cycle instructions like TXA. Data is fetched from some address and discarded. Probably the next instruction is fetched twice.

A comment about the NTSC emulation in xvic: it is quite good, but not perfect. I have been working on a NTSC conversion of VIMMII and one part works right in the emulator but the graphics is a bit messed in the real machine (screen is shifted two lines). I'll report the reason when I know what the problem is.

-Pasi

[carlsson]

I have a few ideas how to experiment further, but unless someone proves me wrong, I think Viznut's text points out weakness in emulation rather than new graphic possibilities.