Mucking around on the Commodore 64 DTV

[rubber_jonnie]

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

Good stuff :)

[mrbombermillzy]

As I was in a stalemate situation with other projects (see viewtopic.php?p=136881#p136881) I recently decided to have a fresh look at where I was with the C64DTV.

IMHO, theres not much that gives the same level of satisfaction as finding and fixing a 6 month old bug that has deadlocked a project. :D

And here we are...

I managed to fix the loading bug in the VICE DTV codebase:

viewtopic.php?p=127130#p127130

which with finding the correct VICE DTV drive settings - has unlocked the key to further progress.

Ive not got much further yet, but have managed to set up a file naming suffix system where a file can be split into 32Kb or less 'chunks' and the whole chunk set will be automatically loaded to DTV RAM.

So the C64 memory map is set up with a 32Kb window (hence the max. chunk size) and the loader will load each file in the split whole, up to the 2Mb DTV RAM limit automatically. :)

Whilst the screen blit size is incorrect (as you can definitely tell below) and I have not failsafed the routines (for things like rollover/overflow catching) and various other things (data stream continuous alignment checks and also it only works with my interrupt service routine for blit raster timing removed), it looks like Ive cracked the successful loading of >32Kb asset (64Kb in this case) to RAM/screen RAM:

Loading assets.png

Yeah, it looks crap and not not a massive progress update but Im exited. :lol:

:girldance:


More to come sooner now I can resume the work.

[mrbombermillzy]

Ok, so whilst the real DTV is in need of repairs, further progress has been made with the VICE DTV emulator, although not as quick as expected.

The reason being, that even after fixing the problems I described above, it seems that the DTV ROM Kernal was still not finished antagonising me.

I was having problems loading image data into my remapped C64 RAM 32Kb 'window' (starting at $4000/16Kb). The reason for the $4000-c000 window location was that the DTV uses a paged/banked RAM system to be able to switch RAM that the 6502 accumulator/x/y registers can access. These banks are segmented into neat 16Kb sections and it would have been nice to load to that section and then switch it out to high mem.

It seems whatever I did, I could not get the image to display correctly at the (switched) $10000 RAM area; the image transferred was the latter part and only a short amount of it: (the 32Kb loaded GFX chunk should take up half the active screen)

Screenshot From 2026-05-05 19-42-33.png

No amount of hacking or dirty fixes could fix the problem. So in the end, I had to create a visual test program which - using the joystick in port 2 - can scroll through the whole 2Mb of RAM and displays the contents on screen in real-time. I even added a border colour correlation with the upper word of memory, so that the border colour (in the standard C64 colour palette) represents a particular 'page' in the DTV RAM. (The DTV bitmap mode selected displays almost a full 64Kb 'page' per screen. The test program shows a different C64 palette colour for each of the 16 x 64Kb memory 'pages' in the DTV:- up to 1Mb anyway, then it repeats).

At last, the real problem begins to present itself after loading the first (32Kb) half of the image without bank switching in place:

Screenshot From 2026-05-05 19-31-31.png

*excuse the upside down image: spoiler alert... FYI images are actually stored in .bmp files upside down.

As indicated by the border colour Black (colour 0 in C64 palette), we are sat at memory 'page' 0. (Apologies for the sub optimal graphic image; due to the nature of the diagnostic visualisation program, the first 16 colours of the 256 colour palette have been changed to standard C64 palette colours, so I can more clearly check which DTV RAM 'page' is being shown. Unfortunately, this makes 16 colours of the image wrong and the colours at the top of the screen are a bit more affected.

(Interesting side note, below the plain black block, just above the yellow/black striping, are the program variables which actually respond visually to changes in real-time. The very top of the image is system variables, routines and data <2Kb).

Anyway, this slight colour mismatch inconvenience is made up for by the fact we can clearly see that the graphics data is being initially loaded to the C64 standard start of BASIC area $0801 which I believe is the place that the ROM Kernal LOAD routine would begin storing its loaded data if neither of the x/y registers hold a relocation address and the address in the file header is not set to be used.

Amusingly, after consorting with Googles AI to ask specific questions about the issue - and the reply quite often being articles written by myself on this very thread as a reference - all semblance of confidence in any further replies fell through the floor. :lol: :roll: It felt like some sort of downward spiralling feedback loop.

Anyway, after some consideration and taking the AI answers with extreme prejudice and suspicion, the crux of the matter appears to be that the DTV version of the C64 ROM Kernal does not re-locate the start of loading address, whether through conventional means (setting x and y registers to the address in LOAD function and flagging alternative address loading in SETLFS function) or by less conventional methods (changing the start of BASIC in $2b/2c to where I want the data relocated).

Either way, the end result was that the computer said 'no'. There is likely an alternative, but short of stumbling across a fix (which wont happen when Google AI references non DTV articles or ones that I have written!), patching the DTV ROM or writing my own custom IEC loading routine - quite unlikely at this point, I have instead decided to keep it simple - for now. At least until I have some other parts of the code working!

This means that the 16Kb bank/segment paging system cant be neatly switched now unless I buffer around 14Kb of RAM with useless boundary padding data to align with bank 1 ($4000/16Kb), which Im not going to do either. So like I said; simple as possible, until a time - if at all - when it is no longer viable to do so.

Well, I suppose my tidy self created asset/program memory map is pretty much ruined then, but I guess I can work around the kinks; I will place the code/code data somewhere else and use the start of BASIC area as a 'scratchpad' and get the blitter or DMA to move assets loaded there into higher DTV RAM. Not what I wanted to do ideally, but seeing as the asset discovery/sizing loading routines that Ive created are quite comprehensive already, I wont rock the boat too far ATM, as I could do without that extra headache at this stage.

TL;DR: I cant use RAM page/bank switching and have to use DMA/blitter to move asset data!

[rubber_jonnie]

Ok, so whilst the real DTV is in need of repairs...

Oh no, what's wrong with it?

[mrbombermillzy]

The 4 wires from the power switch pinged off a while ago as detailed here: viewtopic.php?p=136881#p136881

Its been sat waiting for an 'enclosure' it can be put in so that nothing moves so as not to ever so slightly disturb and therefore loosen the easy break wires yet again. :roll: