Mucking around on the Commodore 64 DTV

[mrbombermillzy]

So heres a bit of an update...

The next task, if you remember from the last post, was to remove the 16 bit multiplication from the block display code and replace it with linear screen value look up data.

Well, this took a bit longer than expected, as I was stuck on a piece of code that was adding the (unknown to me) already set carry flag during an addition instruction.

Looking at the debugger, I was getting a value of $41/65 in the recently set to =0 accumulator when adding a memory location that contained the value $40/64.

Thats all well and good, but the $1 brought into the addition calculation from the carry flag I still am not sure where it was set from, but never mind now...I just had to clear the flag (clc) before the adc and it all worked fine after that.


So apart from the initial screen block placement (which only happens once until the character leaves the screen), there are no other places in the code that use the mul16 multiply routine.

Although its a bit rough, I have recorded a video (using a 25fps old camera before it died) to compare the multiply calculated character block placement to the look up table pre-generated data version.

They are shown one after the other:

dtv.zip

(7.19 MiB) Downloaded 6 times

(Sorry for any inconvenience, I dont have a YT account, the zipped video shouldnt be a problem to play though).

Now if youve watched the video, although its not night and day, if you look closely, the speed difference can be seen.

According to the clip file lengths that I edited so they were each cropped from the start of the move to the end of the move and no more, I get:

multiply version: 1.97s
lookup data version: 1.73s

Not a bad time save, but would have been much better if perhaps the multiply routine wasnt so quick!

Ok, thats it for tonight.

As is probably blatantly obvious from the video, the next task is to stop the flickering.

This is due to moving the block out of sync to the screen draw times. A method has been discussed in an earlier post of creating a blit list which loads up all the blit jobs into a close task cycle proximity and gets started at the best time (likely to be when the screen refresh is at the top of the screen).

But there is much more work to do in that department.

Until then, I might branch off and try other stuff to make things interesting.

[mrbombermillzy]

Im still making progress, but I think its time for a bit more fun...

So I have decided to take another look at overscan, to see if I can get things looking a bit better.

We are also going to hunt for the border locations in memory.

So lets start with an image of what the regular 320x200 screen looks like, courtesy of build DMAsc038:

DMAsc038.png (99.71 KiB) Viewed 124 times

Now I have changed the game variables to accomodate the extra screen size, extended the map data and adjusted the pre generated y axis positional data (see last post), so that the blocks are correctly positioned for a 384px wide screen and voila:

DMAsc039a001.png (117.41 KiB) Viewed 124 times

So we have some nasty HW overscan related bugs to the extreme right of the image (which we will properly try to tackle later).

But for now what can we do about the stripey black/yellow colours above and below the screen? (FYI a write to $d020 like on a 'regular' C64 to set the border colour doesnt work).

Well, lets find out...

Luckily, before asserting that the blitter was much quicker than the DMA, I coded a simple DMA screen fill routine, which copies a single source data location (which happens to be the correct value for displaying the colour black) and moves it over a 320x200 screen to clear the screen before any drawing is done.

Anyway, I can modify this routine to find where in memory these stripes reside, by changing the destination DMA block move starting address.

So apart from the slightly fatter stripe immediately below the active screen display in the picture above (which is still part of the active screen and is just black/yellow because that last bit of active display area doesnt have a graphics block over it), the top and bottom borders are not adjacent to the active screen memory.

In fact, from my initial mucking about, it is very strange indeed.

Its almost as if the borders are made up of 4 repeating memory values.

I can set a DMA block transfer (of colour red) to show one of the 4 lines being changed:

DMAsc039a003.png (4.26 KiB) Viewed 124 times

by doing this with the DMA registers:

DMAsc039a004.png (34.68 KiB) Viewed 124 times

if I then add 2 to the DMA length, I logically get 3 of the 4 stripes coloured:

DMAsc039a006.png (32.58 KiB) Viewed 124 times

DMAsc039a005.png (3.52 KiB) Viewed 124 times

But both the DMA register value sizes and the actual target address dont make logical sense, otherwise I can change them from what they are:

Destination: $400 (Generally the default standard C64 Screen RAM area, but who knows what it affects on an emulated DTV!)
DMA Length: $40f/1039bytes
Destination Line Length: $40 Shouldnt make any difference,as Dest. Modulo is $0000, so no mem jump should be made (it should be contiguous)

to this:

Destination: $800
DMA Length: $0f/15
Destination Line Length: $40 Shouldnt make any difference....see above

...to cancel out the long $400/1024 bytes of useless transfer and just do the important last 4. However, I just get the regular yellow/black stripes and no sign of red.

I dont know if something is amiss with the emulation, the HW, or I am just particularly tired tonight and am missing something obvious. Ive also noticed with other combinations, that changing the Dest. line length *does* affect the outcome (I dont believe it should if the modulo isnt set).

Still more puzzles to solve then, but at the end of the day, I can still colour the border (in this cumbersome fashion), so can show an example of how we can disguise the right hand screen corruption, by the use of a suitable background colour:

(Top/bottom borders left on, to show the full border colour coverage when DMA length is $040f and the 'unpainted' stripey bottom screen edge left in for good measure ).

DMAsc039a002.png (106.39 KiB) Viewed 124 times

As you can see, the yellow/black lines are gone on the right, but we still have a glitchy screen repeat for the last ~20px of the screen edge. This may have to be covered up, unless a solution is found to avoid it. I believe changing values at certain points on the line (a la ST L/R border removal) works, so may try to do this at some point.

Anyway, thats it for now.

Maybe next time we will cover some safer, less experimental ground, with the game engine progress...or not! We will see how I feel.

.

[mrbombermillzy]

Just a little update...

No fancy screenshots, as externally, its the same look as before.

However, Ive streamlined the backend to be both assembly 'library routine' and compiler friendly.

As part of the progression was to get assets loading into >64kb DTV (read fast) RAM, I have been slowly building up an easy to use (from assembly) MACRO for loading asset data. This will allow me to load some 'proper' (up to a theoretical 2Mb) sized graphics and perhaps do another Mortal Kombat demo, like on the ST.

Whilst the routines are fairly complete now, I am having some issues getting them to work.

The problem being that I cannot get VICE DTV to successfully load a file from a (virtual) 1541-II using the Kernal function calls.

As far as I can see, Ive supplied the passing requirements (in a/x/y) to the function, but VICE doesnt even look to be accessing the drive and just displays a continual changing single character on the screen and the program goes into a infinite loop and doesnt continue my code.

So, in slightly more detail, Ive setup/called SETLFS, SETNAM, LOAD and READST.

The real question(s), I guess would be whether the DTV ROM Kernal has any errors, or if VICE properly emulates the 1541-II in DTV mode or even the DTV emulation itself is accurate in this regard. Otherwise, I will never get it to run using conventional bug finding processes. At the very least, I cannot proceed with the conviction/confidence of stuff being right, as I cant be 100% sure either way if the problems are manifesting in the code or the HW.

And seeing as there are probably not much more than a handful of people on the planet who can answer the above questions with any sort of authority (i.e. not a guess), I may have to either try to contact them, or soldier on and properly bug track what happens in fine detail.


So overall, progress is being made, just quite slowly at this point.

May leave this for a bit to brew and continue on the ST port.