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

(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! :lol:

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

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

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

by doing this with the DMA registers:

DMAsc039a004.png

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

DMAsc039a006.png

DMAsc039a005.png

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 :P ).

DMAsc039a002.png

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. :D

.

[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. :coffee:

[mrbombermillzy]

Alright, so finally we continue the journey (albeit slowly at first)...

Thanks to the efforts of @rubber_jonnie (as well as the original modding, thanks to @PhilC ) I now find myself - along with the other 'enhanced' 8 bit systems - the owner of a 'real' modded C64DTV v2 again and no excuse to not keep dabbling or 'mucking around'. :D

So the first thing (after clipping a damned pinged off power wire and then checking out the various demos/utils for real) was to check my code parity on a real device with respect to the VICE emulation.

Unfortunately, it seems the latest emulator code builds I have written are far from working on the real thing; a blank black screen is the best I get... Time to backtrack to (hopefully somewhere that matches and works).

So starting from the latest (with the character overlaid on the castle wall block backgrounds) which was build number 45, I now have to revert back to build number 8 (ouch! :shock: ) before I see any code that matches the emulated output. :roll:

To add insult to injury, my in place TFT TV has now manifested some sort of backlight leakage issue on the top of the screen. Please forgive the blamange puke at the top third of the screen. :lol:

Here we are then; build no.8 - which is doing a DMA block transfer to the screen...

On emulation:

DMAsc008.png

On the real DTV:

DMAsc008R.JPG

and here is the image moved left so you can see it better:

DMAsc008R2.JPG

Ok, so far so good; generally no real problems yet (other than that damaged screen).



Next is build no.10, which is blitting from the C64 (<64Kb) RAM.


On emulation:

DMAsc010.png

On the real thing:

DMAsc010R.JPG

This is where things start going wrong. A closer look at the blit image:

DMAsc010R2.JPG

Of course, I will need to investigate. It looks like some sort of blitter transfer register bug.


To confirm it is only related to blitter transfers, here is a DMA and blitter transfer to the screen...

On emulation:

DMAsc011a.png

And with one of the images changed to the Atari logo and on the real DTV:

DMAsc011R.JPG

With a better look (damn that screen):

DMAsc011R2.JPG

It looks like there is either an over reach bug on the image transfer amount, or on the under reach black restorative blit amount (the white horizontal line where the image has been moved over to the left).

Also, you may notice the smaller anomalies (on both blitter and DMA tranfers ); stray pixels outside the image box borders, image edge colour clip anomalies and of course the big problem being a monochromatic blit image colour.


So there we are.

The moral of the story; dont get too carried away with coding on a less than fully accurate emulator for a less than fully fixed HW platform. :lol:

Now comes the daunting task of stripping down the blitter code - bit by bit - and seeing if I can find the issue.

On top of that, I need to compensate for the littler bugs/anomalies with the images.

All the while, having to transfer SD cards over from my dev laptop to the real machine and all the copying/slow loading and fiddling around with .d64 images that entails. :roll:

Oh well. Lets see what can be done.

Stay tuned for the madness that prevails.

:crazy:

[rubber_jonnie]

Alright, so finally we continue the journey (albeit slowly at first)...

Thanks to the efforts of @rubber_jonnie (as well as the original modding, thanks to @PhilC ) I now find myself - along with the other 'enhanced' 8 bit systems - the owner of a 'real' modded C64DTV v2 again and no excuse to not keep dabbling or 'mucking around'. :D

So the first thing (after clipping a damned pinged off power wire and then checking out the various demos/utils for real) was to check my code parity on a real device with respect to the VICE emulation.

You're welcome :)

What happened with the power wire BTW? It was pretty well attached when I handed it to you.

Good luck with the project and let me know if you need me to test anything for you.

[mrbombermillzy]

What happened with the power wire BTW? It was pretty well attached when I handed it to you.

Who knows? It seems to always happen with the bare minimum of provocation. Maybe it snagged on a connector in the bag on the way home and going over bumps for ~150 miles. I certainly didnt man-handle it (knowing how delicate it is from previous experiences). When I went to carefully take it out of its anti static bag, it was already disconnected. (It was the +5v wire from the back of the actual connector/board to the main circuit:

DTV wires.JPG

Not to worry though, its now in a position where it doesnt have to move at all and I have access to the power button as well as the essential reset. When I have the time, I will dig out the iron and blob it back in place...once I know where its going to live; away from any movement.

Im thinking a C64C case? If I get one of those C= keyboard to PS/2 converter circuits that would work.

Good luck with the project and let me know if you need me to test anything for you.

Thanks. But by that, do you mean as in, you have a built up DTV to test stuff on? Go on. Do it! :D :lol:

Once I get all this inaccurate emulator code base up to scratch with the real thing, I was actually at a point where things would start to get interesting quickly, so I will try to get it running again soon.

[rubber_jonnie]

Who knows? It seems to always happen with the bare minimum of provocation. Maybe it snagged on a connector in the bag on the way home and going over bumps for ~150 miles. I certainly didnt man-handle it (knowing how delicate it is from previous experiences). When I went to carefully take it out of its anti static bag, it was already disconnected. (It was the +5v wire from the back of the actual connector/board to the main circuit:

That's a bit annoying, at least you're on the go again.

Not to worry though, its now in a position where it doesnt have to move at all and I have access to the power button as well as the essential reset. When I have the time, I will dig out the iron and blob it back in place...once I know where its going to live; away from any movement.

Cool.

Im thinking a C64C case? If I get one of those C= keyboard to PS/2 converter circuits that would work.

Sounds like a plan, I bet you could find a dead C64C relatively easily

Thanks. But by that, do you mean as in, you have a built up DTV to test stuff on? Go on. Do it! :D :lol:

Once I get all this inaccurate emulator code base up to scratch with the real thing, I was actually at a point where things would start to get interesting quickly, so I will try to get it running again soon.

I'm certainly up for it, but not home from France until late tomorrow evening so nothing immediate. Of course if I'm needed to test stuff then it might hurry me along ;)

[mrbombermillzy]

Sounds like a plan, I bet you could find a dead C64C relatively easily

Im looking to rehouse the breadbin that you recently pimped up into a bigger third party C64 case. That would give me a spare case. Then it would just be a keyboard to find...and some connector templates, glue and/or screws. :lol:

I'm certainly up for it, but not home from France until late tomorrow evening so nothing immediate. Of course if I'm needed to test stuff then it might hurry me along ;)

Good heavens no. :)

As you are now aware from a recent PM, Im quite short of time at the moment and as described earlier my [code>compile>debug] time has increased by approx. 1000%, so its going to be much slower now to debug.

I was using some really fabulous/rapid code tools on the laptop, but Im afraid that VICE wont do anymore, as has been seen in the previous post photos and I have to use the real thing - which doesnt have something amazing like the KickAss/Relaunch64 combo available.

Sadly, this means after writing the code, transfer across to the DTV by SD after firing up a 1541 disk writing utility and updating the virtual floppy image with the new PRG. Then putting it into the Rpi, booting that up, booting and resetting the DTV, loading the file - ~3 mins just loading - and then running the file.

Previously it would take one click and selecting a .d64 image (about 15 seconds) from finish writing of the code to displaying the compiled and run results. :roll:

So as you can see, that at least gives you plenty of time to mod your own DTV before I have something to send your way. I will keep you well posted on progress though. ;)

Also, I may well branch into some DTV side projects; e.g. sample synthesis/MIDI and GFX related and such like for a while and return back here. :D

[rubber_jonnie]

So as you can see, that at least gives you plenty of time to mod your own DTV before I have something to send your way. I will keep you well posted on progress though. ;)

Also, I may well branch into some DTV side projects; e.g. sample synthesis/MIDI and GFX related and such like for a while and return back here. :D

No worries at all, just understand that I am ready willing and able to help with the project whenever you need me to :)

[mrbombermillzy]

No worries at all, just understand that I am ready willing and able to help with the project whenever you need me to :)

:2k2:

Thank you for your support.

You will be my first line of contact for any testing (or when something interesting happens). :)