Mucking around on the Commodore 64 DTV

[mrbombermillzy]

So myself and @PhilC a while back were mucking around with C64 DTVs.

We are close to getting the units working as almost 'proper' C64s, with keyboard, FDD and joystick ports.

Unfortunately, we have both struggled to find the time to get to the bottom of the issues.

However, in the mean time, I have taken to trying out some experimenting in 6502 assembly with the VICE DTV emulator, ready to try on the real thing when we get it sorted.

And oh how easy things are with a fully set up system of Relaunch64, KickAss and VICE. I was anticipating something from the 'bad old days' of C64 assembly coding, but the run>debug>compile time is absolutely minimised. Even more so if you select the 'inject to RAM' option, as you dont then even have to warp speed load your program, it just gets laid into RAM, so instant running.

Moving on...

For quite a few years now, I have had the C64DTV as a target system (even as possibly a subset of the full game engine) for the game Ive been working on.

With that in mind, Ive been exploring all the new possibilities that Jeri Ellsworth has added to this great little system.

For those unfamiliar with the C64DTV, it is a fairly complete ASIC implementation of the C64, but with some added (as well as lacking) features:

Added stuff: (DTV v2+)

* 2Mb ROM
* 2Mb RAM
* Blitter (has some cool source and/or destination scaling options)
* DMA
* 256 colour 'chunky' mode
* Overscan mode (broken, but can be compensated for)
* Up to 15 of each A, X and Y registers(!)
* Skip internal cycle/burst mode for >64Kb SDRAM speed boosts (this allows in theory for up to a peak 4 MIPS operational speed of the processor)
* 8 Bit sample playback (on top of SID playback)
* extra ADSR envelope types

Some other bits are included, like less bandwidth intensive graphics modes (Fred1/2), etc.

Bad points:

* The SID filters are not present (probably the biggest negative point)
* From what Ive attempted so far (and from details back in the day) DMA/BLT units are a bit buggy. (Alpha and modulo problems; some fixed in DTV v3)
* Overscan mode is broken but can be used with work arounds (in a similar way to how the ST border needs switching at specific points for overscan).

Right then, enough of the details, lets start some action!

So to start with (bear in mind, Im *only* using the enhanced features of the DTV), lets set up the screen for chunky 256 colour mode and DMA transfer a image to the screen: (grey border colour is the actual raster time taken to transfer data to screen via the DMA system)

DMAsc008.png (35.13 KiB) Viewed 14533 times

So far, so good...

Now lets try moving the block (in which case, we need to erase the previous contents; easy because the background is black):

DMAsc008a.png (35.35 KiB) Viewed 14533 times

image transfer = middle bar, Erase transfer = bottom to top bar; both from C64 RAM (<64Kb)

Here we see that we are nearing the limit of the DMA time for a single frame.

Depending on the if the blocks are moving, and if so, how fast they move, I will guess that we can move just over 2 64x64 blocks (size of the one in above picture) moving at 1px/frame.

The reason that the whole of the frame is almost spent in the above picture and there is only one block present, is because of my utterly inefficient erase block routine, which is actually blanking out the *whole* previous 64x64 block; something that doesnt have to be done unless the block is moving over 64px away from its current position in the next frame (which you will generally not be doing).

In any case, lets now have a look at what the blitter can do, but before we do, let me just post this 'politically correct version for this forum' DMA transfer pic:

test15.png (26.85 KiB) Viewed 14533 times

Ok, same tests, but now with the DTV blitter:


First up, Blitter (from C64 RAM ($c001)) :

DMAsc010.png (31.99 KiB) Viewed 14533 times

Much faster eh?

Blitter + erase (from C64 RAM):

DMAsc010a.png (30.83 KiB) Viewed 14533 times

Blitter (from DTV RAM ($6c001)): (sorry, didnt move the picture into >64Kb DTV RAM for this; oops!)

DMAsc010b.png (14.66 KiB) Viewed 14533 times

Blitter + erase (from DTV RAM):

DMAsc010c.png (13.7 KiB) Viewed 14533 times

DMA + BLT both from C64 RAM ($c001): (Raster time bar changed colour to dark red BTW)

DMAsc011a.png (53.74 KiB) Viewed 14533 times

DMA + (BLT+erase) from C64 RAM:

DMAsc011b.png (54.02 KiB) Viewed 14533 times

DMA + BLT (BLT from DTV RAM $6c001):

DMAsc011c.png (37.92 KiB) Viewed 14533 times

DMA + (BLT+erase) (BLT from DTV RAM):

DMAsc011d.png (38.98 KiB) Viewed 14533 times

DMA + BLT (Both from DTV RAM):

DMAsc011e.png (20.77 KiB) Viewed 14533 times

DMA + (BLT+erase) (Both from DTV RAM):

DMAsc011f.png (21.93 KiB) Viewed 14533 times

As can be deduced from the above images, both using the blitter *and* using the (>64Kb) DTV RAM are the faster options (as well as optimising the erase block routines lol).

I estimate around 5 64x64px blocks can be transferred per frame (just over double the DMA transfer rate).

Therefore, the wisest choice in the next step is to use BLT with images from higher DTV RAM to display a series of blocks across the screen, as would be done in a game.

Im sure the DMA will also come in handy and can be used to transfer audio data, or even perhaps 'feed' the blitter registers. Only time will tell.

I will take a breather for now though.

[exxos]

Impressive stuff we need to see the little man in the air balloon flying around at some point

[PhilC]

Good work @mrbombermillzy. I have a couple of keyboard PCBs here if you wanted to put your DTV into an original case.

[mrbombermillzy]

What sort of PCBs are they Phil? Are they some sort of PS/2 keyboard adapter?

(Also remember, whatever the answer, I dont like words like 'PCB', so I'd be trying to send it back your way if any sort of soldering is involved!)

[mrbombermillzy]

@exxos well, thats going to be fairly trivial, as converting an image is as simple as grabbing a DTV palette (indexed) in Gimp or whatever and converting a picture to that, then saving/exporting as raw data.

The hardest bit is getting the DTV palette (which is easy to get).

[mrbombermillzy]

Here is my dabbling progress with the interesting blitter scale registers.

As my game assets are factored for a PC with a 1024x768 screen size (and the 64x64 blocks are in a 16x10 matrix), I wondered if it would be possible to try changing the source zoom levels to match my original screen resolution.

Now using some of my game block image assets, rather than keep having to convert an arbitrary image like before, here are the results:

First, the initial block at full scale: (note the image size error on the right edge; a bug of the DTV blitter)

DMAsc013a.png (18.84 KiB) Viewed 14482 times

Now, lets scale the source image to double: (pseudo 640px x axis resolution)

DMAsc013b.png (27.24 KiB) Viewed 14482 times

Now lets go crazy and go right down to 1/6th size: (that gives us up to a pseudo 1920px x axis resolution! lol)

DMAsc013c.png (31.23 KiB) Viewed 14482 times

So scaling works as described, and may also possibly come in useful for eliminating the errant pixel column on the block images:

DMAsc013.png (3.17 KiB) Viewed 14482 times

[PhilC]

What sort of PCBs are they Phil? Are they some sort of PS/2 keyboard that fits the C64/C cases?

(Also remember, whatever the answer, I dont like words like 'PCB', so I'd be trying to send it back your way if any sort of soldering is involved!)

It's the C=Key Adaptor to use a C64 keyboard as a ps/2 keyboard. I'll make a couple up

[mrbombermillzy]

That sounds ideal Phil.

Would love the DTV in a C64C case.

PM me and/or I can sort you out at CL3. Thanks.

[mrbombermillzy]

Just one last step for tonight...

So instead of just displaying the source image blocks as is, copied straight to the screen in the same order (as in the previous scaling example), Ive coded a routine which now displays the correct block in a matrix/indexing system, so I can now manually write map data to display whatever blocks at whatever positions on screen:

(apologies for the crap rounded wall effect in the mid 3 blocks: the 'quick and dirty' image colour conversion ruins the effect somewhat)

DMAsc017.png (237.89 KiB) Viewed 14448 times

Now we are starting to see the issues with the blitter block size and its problems. I havent gone too far attempting to fix/compensate for the blit errors, but I guess I will have to at some point.

[mrbombermillzy]

Unfortunately, with the DTV HW being buggy, I sometimes slip into the thought process that its the HW at fault and not my code.

But I will admit here and now that in this case, it was my blitter register tables, hidden far away from the main loop causing the problem .

So, returning to the map data, its pretty much fixed now:

('pretty much' = still an errant single pixel column on the left of the image I have to investigate)

DMAsc019.png (245.03 KiB) Viewed 14356 times

However, now is probably a good time to look at the DMA and blit block errors in more detail.

Lets start with a reference image, you all should appreciate:

Atari.png (12.3 KiB) Viewed 14356 times

So this is the source image. To help identify errors, I have placed border lines around all 4 edges of the image;

red=left, green=bottom, blue=right and white=top.

Ok, so both the DMA and BLT of the above image produce the below discrepancies:

DMAsc008b.png (16.12 KiB) Viewed 14356 times

Not too shabby you may think, or is it? Lets have a close up of the top right corner:

(removing as much emulated 'blur' and colour related aliasing errors as possible to show the problem)

error1.png (9.93 KiB) Viewed 14356 times

With the 'sphere' image from earlier (with the same border colour conventions):

error2.png (27.94 KiB) Viewed 14356 times

As you can see, theres some sort of issue where the transfer 'drops the ball' and seems to do a sample and hold style error on the data in the top right of the first line.

It could possibly be something Ive overlooked, but generally, if the line length or modulo values are out (coder error), its pretty obvious and you will get some sort of big image skew/distortion visible on the whole image.

So while Im racing ahead, putting up full screen graphics, at some point, I will have to 'roll back' and attempt a thorough DMA/BLT transfer error investigation to get some answers.

This may not happen until I actually test on real HW, as, you never know it could be unfixed/unreported emulation bugs.