Mucking around on the Commodore 64 DTV

[PhilC]

That sounds ideal Phil.

Would love the DTV in a C64C case.

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

Yes we can sort out for CL3, will get the extra Atmel chips ordered when I get a mo.

[mrbombermillzy]

I'd really appreciate that @PhilC . :) Thanks. PM me to let me know what I owe you.

Also, if you find you have too many 1541 drives and want to leave one on the corner of my table at CL3, and in exchange pick up an envelope with cash...

:lol:

Seriously, coding for the DTV has made me remember how much I loved my old C64, so Im looking to grab a 'real' floppy drive again at some point and maybe code some audio/sampler/MIDI type programs. (Also test a real 1541 with the DTV).

[PhilC]

@mrbombermillzy I think I've got three 1541s at the MO :lol:

[mrbombermillzy]

@mrbombermillzy I think I've got three 1541s at the MO :lol:

Well, if you ever decide you can let one go, let me know. :D

Im still gutted that I missed out, a guy (In the US IIRC) was selling 1581 drive 'kits' very cheaply 10 odd years ago. I already missed the boat on that by the time I found out about it.

Them drives are silly money now, or 'LOL Price' as they say around here. :lol:

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

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 .

After more mucking around, I would like to redact that comment.

What I had actually done in an earlier build was try to make the best of a bad situation; i.e. cover over the blitter bug with another tile image so it doesnt get noticed hence the 'almost perfect' last image (on the previous page) of the screen tiles with one column of errant pixels on the left edge...this is an extra column of pixels from the previous line!

Here is a solitary block, to show the error to full effect:

bltbug.png

The blitter is therefore rendering 65px to the screen instead of 64 (and showing the first pixel column of the next imageblock in the source image). Any attempt to shorten the line length (to 64px) and increase the modulo respectively to compensate, results in chaos of one sort or another; 45 degree sloping blocks in 1, 2 or 4 directions, etc.

Or even this, which doesnt even make logical sense to me...

bltbug1.png

...as the 'so called' incorrect modulo/line length doesnt seem to pull in the contents of the next image, as it should do:

bltbug2.png

As an aside to this headache, if you want to see what else is seriously wrong, then lets enable overscan mode after first 'correcting' the block display again:

oscnbug.png

I guess I will have to leave overscan mode alone for now.

At least with the blitter bugs, I can slap some lippy on and at least make it appear nice. :lol:

Ive not really tackled overscan yet, so am unsure of any fixes so far.

Im sure I will get to the bottom of it all at some stage.

[Higgy]

Am I right in thinking you need the original model 64 DTV to do decent mods?

I looked it up years ago but have now forgot.

I bought 2 about 10 years ago from eBay, but they both ended up being the NTSC versions! I noticed as I was getting a B&W display on composite (LCD TVs seem more forgiving on NTSC composite so you might get colour).

[mrbombermillzy]

Am I right in thinking you need the original model 64 DTV to do decent mods?

Technically, no. Let me explain.

The first DTV was for the NTSC market (v1) and had several more bugs in the HW, low reflash till fail flash chip, 128kb RAM (instead of 2Mb), etc.

The v2 was both NTSC and PAL, fixed several bugs/problems and around halfway through the production run some extra fixes were pushed through and this is what is called the v3.

There is also a NTSC 'Hummer' steering wheel which I believe is also the same 'fixed tech' level as the v3.

I think you'll find, you can do most of the 'regular' mods on all 3 DTVs, but obviously, if you are from the UK, you will want to avoid an NTSC unit/v1.

v3 is the ideal purchase, but they dont have a big golden sticker on them with 'V3' written on it and visually, you cant really tell. You wont really know until you try it out, modded up.

I think when me and @PhilC were trying to figure the board mod locations/issues, one of our donor DTVs turned out to be NTSC.

I dont think the outer case manufacture date markings really help. You'll have to prize it apart and look at the board Im afraid. (Even then, you may need to run some test software to check if its v2 or v3).

HTH

[mrbombermillzy]

So having recently been on holiday with no internet and the fact that most of my current code projects HW needs fixing and are otherwise not emulated (e.g.: TF536+ET4000), I decided to continue with the (emulated) DTV project code.

This post is more of a technical overview, rather than a progress report, to help digest any later discussion of coding/architecture which may arise during future posts. Im more than happy for any 6502 (or indeed DTV) experts to chip in if there is a better solution for anything being discussed here. Im pretty much a C64 coding noob (last coded an assembly game on the C64 ~38 years ago! lol) so may well appreciate any cycle reducing tips. (Esp. in my 16 bit multiply routines).

So, continuing on, the next milestone for the DTV is to create a background tileset which reads from a matrix/table (which I have already demonstrated) and then overlay a player/sprite over it, along with some basic movement (for now).

Rather than continue with the 'quick and dirty' code tests which as we all know, will snowball into a big horrendous mess, I have decided to take what has been done so far and roll it back and rebuild the codebase to a more structured and (hopefully) flexible system which can be used to display the background imagery whilst overlaying some 'sprites', or player characters and moving objects with easier MACRO use or clearer routine jumps as needed.

Like I mentioned elsewhere, the code design/structure will follow a similar vein to my DC1 game engine; obviously taking into account any design/layout changes due to the limitations of the DTV HW.

Fortunately there are a few things that are to my advantage here:

1. The DTV hardware - if I am correct in believing if harnessed correctly - can in theory be an Amiga killer (I mean as a complete system its roughly closer to a A4000-030, rather than a A500). The graphics system is native 8bpp chunky format, so no having to deal with high colour planar interleave multiple block write shinnannigans, or (from an Amiga perspective) any RTG library call overhead ( (N)VDI equivalent for Atari system). Whilst we could argue the DTV CPU average instruction time of close to 4 cyc, compared to higher peak 68030+ CPUs, the point here being to illustrate (rather than incite a flamewar lol) that all this helps to up the bar somewhat.

2. Another good trick available to the DTV is being able to use the zeropage for pointers with its associated ZP lower CPU cycle overhead (although the C64 is limited to *nearly* 256 memory locations for this). With the DTV hardware however, its possible to 'page in' up to 128 different zero pages! I will probably take advantage of this feature heavily for multidimensional arrays.

3. The absolutely amazing coding tools available for the C64. Some of which have bled over into the DTV. I am able to code, compile and debug at a much faster rate than before (infact, the tools are better than what I currently use for the ST/68k machines). On top of that, the assembler I am using (KickAss) is very versatile and it looks like I may be able to make heavy use of MACROs and 'pseudocommands' to bring the workflow more inline with how my game works. (The plan is to eventually write a frontend compiler for the ST which will convert the original PC code to both Atari ST/Amiga and DTV format).

As for drawbacks, well:

1. My ability! lol. To summarise that; the 6502 CPU IMHO is less elegant (read more cumbersome for higher level code structures) than the 68000 for assembly programming. Fortunately, with the above tools I can reduce the drag factor considerably. In a similar vein, I also have to optimise the code for the (mentioned in point 1 above) lower cycle count DRAM burst mode of the CPU and I have not even attempted this so far. At the moment, Im at the stage of getting things to work at any cost, so that with the fact that Im not a 6502 pro, means that my assembly routine cycle counts are above the norm, rather than being any sort of faster than average C64 code. Who knows? With enough time to get into this, I may be harnessing the above as well as investigating the DTV specific illegal op codes and undocumented features to my advantage. Heres hoping!

2. DTV bugs. Yep. So my real modded DTV is currently in the repair shop, but we established its probably a v2, so Im emulating the v2 for coding/testing purposes on like for like equivalent HW. Whilst VICE DTV emulation is pretty solid, when you start hitting the metal hard you never know where the emulation accuracy will fail. Even so, a pretty basic set of routines can make the blitter HW bugs in the v2 manifest fairly easily:

*Ignore the last image frame; thats my fault!

DMAsc025.png

[DMAsc025.png]

Here is what the screen blit of the sprite frames from DC1 *should* look like (and does with DTV v3 emulation set):

DMAsc025a.png

[DMAsc025a.png]

As you can see, the blit transparency logical operation is doing something weird once every 4px.


Im quietly optimistic that due to the way Im designing the audio playback system, it may be able to affect the bug in a way which prevents it from appearing. More on this when I properly focus on this point.

In the meantime, work will continue on the GFX display system, (as it certainly works correctly on the DTV3) and I will post any progress updates when appropriate.

[mrbombermillzy]

I am almost at the point of something useful now.

Ive established a tile renderer for background tiles in an ordered positional matrix, as well as a character renderer which overlays this.

Ive also created a character image boundary, which limits the character from going off the screen.

And I have just coded a screen restore function to clean up that messy 'snail trail' that the character image creates:

snail trail.png

I still dont have it 100% yet and the restore renderer routines are a bit 'quick and dirty' but its close.

I will have to have another look at it, as the results with setting blitter source image modulo are rather fishy.

To explain the above statement, the source tileset and character image assets are 384x64px size. There is a screen restore buffer which contains an unspoilt version of the background tileset (used to restore the background from the characters old screen data), which is the same size as the screen (320x200).Both chars and background blocks are 64x64px.

Therefore, it would make sense that to go from displaying images sourced from the character assets changing to the restore buffer would need a change in source modulo, no?

In this case, the character source image is 384px; we display 64px which moves the counter 64px forward, we then count to the start of the correct next line position by adding 5x64px or 320 ($140). So we set the low/high byte of the modulo: $40 and $01 in good old 6502 little endian order.

As the restore buffer is 320px wide (and we have already blit 64px) the modulo for this value is 256px ($100); again $00 and $01 for the Source modulo Low and High registers little endian order.

Heres the (admittedly unpolished) code for the abovementioned switch:

Code: Select all

	lda	#$00				// change source modulo from char/block imagefile values to screenbuffer values
	sta	$d323				// Srce A mod L	   
	lda	#$10
	sta	$d324				// Srce A mod H	


	lda	old_char_pos			// put the low (16 bit) byte of the char position calculation into acc...
	sta	$d320				//...and place into Blitter Source Low register										
	sta	$d330				//...and place into Blitter dest Low register								
	lda	old_char_pos+1			// put the high (16 bit) byte of the char position calculation into acc...
	sta	$d321				//...and place into Blitter Source Mid register											
	sta	$d331				//...and place into Blitter dest mid register																						
												
	lda	#Scrnbuffer_base+1				
	sta	$d322						// Source. H													
												
	lda	#Screen_base+1				
	sta	$d332						// Dest. H												
															
Execute_restore_blit:
	lda	#$0f			// set source a,b and dest direction to positive then...
	sta	$d33a			// ...START TRANSFER... 																											
												
	lda	#$00				// then restore source modulo (back to char/block imagefiles) settings [BUG: $00 keeps background/$40 keeps char]
	sta	$d323			// Srce A mod L	  								[TRY SAVING/RESTORING BLT REGISTERS NEXT]	 
	lda	#$01
	sta	$d324				// Srce A mod H												
		
	lda	CharacterGFX0		// then restore char image as source...					
	sta	$d321				//...and place into Blitter Source Mid register										
	lda	#$40
	sta	$d322						// Source. H	

As the astute reader may have noticed (or if not, I will lay it down for you now), at the top, setting the blitter source modulo L/H registers to $100/256 is logical enough to correctly display the restorative buffer imagetiles.

However the fishy moment comes when changing the modulo back (to 320/$140) for the character display blit (towards the bottom; $d323,324).

(Bear in mind, Im using the DTV v2 emulation of VICE, so the blitter HW bug of black vertical lines are 'normal', till I find a fix. :roll: )

With it set correctly (to $140), I get this:

modulo140.png

With it set incorrectly, like the above code shows, I get this:

modulo100.png

Strange...and the fact that I can do a re-blit of the whole screen again and it doesnt affect the character image like this is baffling:

render all tiles.png

However, this is literally as far as I am ATM, so I will recode the above with a more foolproof save/restore of the blitter registers in the start/end of the restore routine whilst sniffing around for any bugs Ive overlooked and see where that gets me. Hopefully Im not working against incorrect emulation bugs in VICE.

Im sure I will get to the bottom of it.

This post is more of a snapshot in my progress, rather than a 'Im stuck and cant move on' type of post. :)

Oh, as an aside, after a bit of mucking around I got a bit further with de tangling overscan:

fullHVoverscan.png

So, after some delving, its not as bad as I initially found and it looks like theres only around 24px of bad data on the far right of the screen.
Notice, Ive also enabled vertical overscan for a hoot (but havent looked at where those black/yellow stripes are located...yet!. :lol:

More dabbling progress later folks.

[mrbombermillzy]

In this post, I thought I would start to delve a bit deeper into the actual problems I have encountered tinkering with the DTV system, as well as introducing some assembly language concepts and problem solving, so that others can perhaps gain from the scenarios introduced.

Ok, so the strange bug that was either causing a distorted character image to be rendered, or the background restored image to be trashed has been fixed.

While a vid would have been better, heres an image of the character having moved left of its original position and nothing has gone wrong: (Ive also cheated and used DTV v3 emulation, which fixes the HW blit bugs, but I will work around those if I can)

DMAsc038.png

So now I can focus on the actual movement of the character, which seems a bit flickery and very likely too slow, once other parts have been eventually added into the mix. The final outcome (it is hoped) being to see if I can create a game engine based on either high level function libraries, or (if I go the whole hog) a low level BASIC language compiler for others to make use of. Im not sure if anything like this has ever been created on the C64DTV, but it will be fun to see how far we can go.

Most (if not all) of the engine specifics will be based on the workings of my DC1 game engine, which is currently PC based. A version is also planned for the 68k machines. (ST to start with, as Amiga already has Scorpion/Redpill/BlitzBasic/AMOS/etc), whereas the Atari has far less choice.

Anyway, I digress...

Where was I? Oh yes, flickery character movement.

I already know what is causing this;

In an attempt to make the code as 'user friendly' as possible, my blitter based draw routines have MACRO based support.

So to draw an image with the blitter (from assembly) its as simple as preloading the variables in the brackets with the required data and calling:

DrawImageBB(Image,x,y,ImageFrame)

Where:

Image is the image base address
x is the x screen position to start from
y ...as above but y
ImageFrame is the actual frame index in the image to display.

All image size and frame sizes are already known and set (but alternatively could be put into variable data and set from the DrawImageBB command itself if required) and the correct source and destination buffers are already set up accordingly.

This is all pretty smooth so far. The problem being, that to hammer this out so it would work, I used a 16 bit multiply routine to transform the (easy to maintain) Cartesian co-ordinates that are fed to the MACRO for x and y, to the rasterised data needed for the blitter source/destination registers.

For those who dont know, unlike the MC68000+ CPUs, the 6502/6510 and the slightly different variant in the DTV do not have a multiplication or division instruction. So creating not just an 8, but 16 bit multiply routine (although pretty quick for what it is), is very costly, processor cycle-wise. Hence the flickering and not particularly super fast speed that we need so we can add extra elements and not bog the system down excessively.

So what can we do?

Well, my favourite rule of thumb, if we have a relatively slow processor, but ample RAM, offload the processing to RAM if possible. What does this mean?

Use pre calculated data tables.

Now, instead of using a slow multiplication routine to calculate image position, I just need to supply the MACRO with the blocks y position (in this case, the character image) and an indexed addressing mode can be used to extract the position for a far quicker MACRO process:

Code: Select all

lda	Char_y															
asl	y							// dont forget to double y index as the data field is words NOT bytes!													
tay								// put acc. into y reg for below indexing											
lda	(Left_screen_lookup data),y	// y is image x axis start of line position	****
sta	Store
lda	(Left_screen_lookup data),y+1	// y is image x axis start of line position	****
sta	Store+1
lda	Char_x+1					// now get the x axis position of char...
adc	Store+1						//...and add it to the first x axis pixel on the screen position...
								//...to get the starting point for the blit destination registers
lda	Char_x						// now get the x axis position of char...
adc	Store						//...and add it to the first x axis pixel on the screen position...
								//...to get the starting point for the blit destination registers

// ****																		****
// **** Where 'Left_screen_lookup_data' holds the leftmost x pixel raster   ****
// **** data position for every single y axis position of the display.		****
// ****																		****

Left_screen_lookup data:	.word	//+320 for every +y axis value
$0000,$0140,$0280,$03c0,$0500,$0640,$0780,$08c0,$0a00,$0b40,$0c80,$0dc0,$0f00,$1040,$1180,$12c0,$1400,$1540,$1680,$17c0,$1900,$1a40 //etc
 

Whilst I havent yet tested the above code, replacing the multiplication of the MACRO with the above should greatly improve the speed of the process.

For the next post, I will install the faster routines and do a 'before - after' video comparison of the speed difference.

In the meantime, I will be looking also at ways to streamline the blit process. Currently, I am blitting individual blocks. Each call to DrawImageBB() is blitting the single block immediately. What I need to do, is change the MACRO so that each DrawImage() call transfers blit data to a list of blit jobs. Then when all the blit jobs have been written to the list (or the frame runs out of time!) the blitter becomes operational and - at the optimum position of the raster beam - begins drawing all the block images all together from data on the list.

But thats some food for thought that needs a bit more of a chew.