Thanks for clearing that up. I wasn't able to reproduce the block-copy error on my C128 (VDC-Version 1 - Rev 8/9) so I assumed the Version 0 (Rev 7) might be the one that has the bug. All better if that is not the case. I can only see one difference in the kernal for Version 0 (Rev 7) in that it sets register 25 to $40 instead of $47. This would be the only change Miro would have to take care of in his programs then. Otherwise I'm afraid he's back to square one with his strange problem if it's not the block-copy bug that causes the problem.

http://myworld.ebay.co.uk/alee650

This seller still has them for sale - just not online at the moment. You can just write him through Ebay anyway. I just go two expansion boards for myself. Arrived in under a week.

I've played around with 50 character-lines on PAL yesterday. According to your earlier calculcations, I set Register 4 to 77 (78*8=624 raster lines) and set register 5 to 1 so I would get 625 lines (= PAL). However any odd value in register 5 leads to the interlace being screwed up as if the interlaced screen is displayed at least a line to low, making the chars unreadable. Any even value however will produce a stable picture with the interlaced chars looking as they should. I tried the NTSC values you are using as well but get the same results, the characters will only be readable with even values in regsiter 5. I'm using a Commodore 1901 monitor at the moment, the original Monitor Commodore suggested for the C128. I'm just in the process of getting a simple monochrome cable for the RGB-port that uses its 50 Hz BAS-signal and once I have this I will do some more tests on my projector.

I'm wondering: Since you are getting a stable picture with odd values in register 5 on NTSC - do you get the unreadable chars with even values?

Furthermore I keep wondering why Commodore chose 640 lines as initital value for PAL instead of 625 or even 624 as would be more logical. Also, why didn't they set register 0 to 127 leading to a very neat 15.625 kHz raster rate (exact PAL). Maybe there is a correlation between the higher raster rate of 15.748 kHz and the 640 lines...? Any idea?

As a bonus, browsing my disks, I found an old 50 char-lines interlace program from the german "64er Sonderheft 22" (= October 1987):


10 fast:bank 15
20 a=dec("cdcc")
30 sysa,77,4
40 sysa, 3,8
50 sysa,0,36:sysa,64,7
60 sysa,50,6
70 poke2607,16:sysa,16,20
80 print "{clr}"
90 :
100 for i=0to1999step200
110 sysa,128,24
115 :
120 sysa,(2000+i)and255,19
130 sysa,(2000+i)/256,18
140 sysa,iand255,33:sysa,i/256,32
150 :
160 sysa,200,30
170 sysa,(6096+i)and255,19:sysa,(6096+i)/256,18
180 sysa,(4096+i)and255,33:sysa,(4096+i)/255,32
190 sysa,200,30
200 next

This is pretty straightforward. It sets register 4 to 77 (= 624 lines) and doesn't mess with register 5 at all, leaving it a 0. It sets the ram-refresh to 0 however as you suggested to as well. I've tried it on my machine and values of 3 in register 36 still work. It has a nice little copy routine accessible by "goto 100" that copies the top half to the bottom.

Quote from: BigDumbDinosaur on March 10, 2011, 12:30 PM
Wrong.  As soon as the loop that tests bit 7 at $D600 exits and the read/write op is done a new register can be written to $D600.

Hmm, I thought so as well, but stumped over the kernal routine, copied in here again for reference:

.C:c53c   A9 01      LDA #$01
.C:c53e   A2 1E      LDX #$1E
.C:c540   20 CC CD   JSR $CDCC
.C:c543   2C 00 D6   BIT $D600
.C:c546   10 FB      BPL $C543
.C:c548   A2 12      LDX #$12
.C:c54a   20 DA CD   JSR $CDDA
.C:c54d   CD 3D 0A   CMP $0A3D
.C:c550   90 EA      BCC $C53C
.C:c552   A2 13      LDX #$13
.C:c554   20 DA CD   JSR $CDDA
.C:c557   CD 3C 0A   CMP $0A3C
.C:c55a   90 E0      BCC $C53C
.C:c55c   60         RTS

This does a check if the VDC is read before the next jump to $cdda. According to my "128 intern"-book this fixes a bug in the VDC block copy (only early revisions maybe?) that sometimes copies a byte to many. That's why the kernal copies one byte less than it should and then does the cmp $0a3d and cmp  $0a3c and copies one more byte if the VDC hasn't already - thus circumventing this bug in every case. Maybe the extra-check for the status flag is in there to make sure the VDC has finished it's block-copy before asking it if it has copied one byte too many. I can't remember having to check the status flag before setting the register in $d600 in my old programs - so I agree with your post. But maybe the error Miro is seeing really DOES have something to do with the block-copy bug in the VDC. But he hasn't addressed that part of my post at all (yet?).

The double-call you do has some serious flaws, take a look at your routine:


vdx_read:
jsr nyet
stx $d600
rvr1: bit $d600
bpl rvr1
lda $d601
rts


When you jsr to nyet in fact THIS gets done by the CPU:


nyet:
   bit vdcstatus
   bpl nyet
   stx vdcstatus
notyet:
   bit vdcstatus
   bpl notyet
   sta vdc_rw   // writting to VDC
stx $d600
rvr1: bit $d600
bpl rvr1
lda $d601
rts


That can't be right... Why do you use separate vdc_read and vdx_read?? And vdc_write, vdx_write? What's the difference. Just make use of the kernal-routines like this:


x=register to write to, a=value to write to register
vdc_write:     
   bit vdcstatus
   bpl vdc_write
   jsr $cdcc
   rts

x=register to read, a=value of register after call
vdc_read:
   bit vdcstatus
   bpl vdc_read
   jsr $cdda
   rts


This is short and sweet and uses the kernal-routines. No need to do separate vdx_read and vdx_write...

As for becoming a co-operator: I'm afraid I don't either have the time nor motivation for that, sorry. I might try some VDC-coding myself again, but this would be for interlace-modes and whatnot, just for fun.

I don't get why you call "jsr nyet" before each access now. You should just check if the VDC is ready again. By calling the subroutine you are adding a lot of unwanted overhead. Why don't you do it just like in the kernal in the first post I sent? This is a small and working solution: Check if VDC-status is ready and jsr to $cdcc or $cdda.

For the block-copy please see the kernal-routine as well - that takes care of the error in the VDC that sometimes copies one byte to many which could lead to the effects you describe.

vdc_write:     
   ldx #$1f
nyet:
   bit vdcstatus
   bpl nyet
   stx vdcstatus
notyet:
   bit vdcstatus
   bpl notyet
   sta vdc_rw   // writting to VDC
   rts

This one looks good. You should do this for every write to VDC-registers if you do them in a row.

You shouldn't just blindly call $c53c before every write, this routine was just to show the quirks of the VDC. Just make sure you wait for the VDC-ready bit before the next write to $d600, like this:
.C:c543   2C 00 D6   BIT $D600
.C:c546   10 FB      BPL $C543
Also make sure the block-copy-routine you use takes care of the sometimes copied extra byte as shown in the kernal code. As this otherwise could lead to unwanted bytes being copied.

Ok, I may have an idea what you are doing wrong. It looks like you check the status register before writing to $d601 but not before writing to $d600. So the VDC may still be busy processing your last command, when you overwrite $d600. Take a look at a kernal-routine at $c53c:

.C:c53c   A9 01      LDA #$01
.C:c53e   A2 1E      LDX #$1E
.C:c540   20 CC CD   JSR $CDCC
.C:c543   2C 00 D6   BIT $D600
.C:c546   10 FB      BPL $C543
.C:c548   A2 12      LDX #$12
.C:c54a   20 DA CD   JSR $CDDA
.C:c54d   CD 3D 0A   CMP $0A3D
.C:c550   90 EA      BCC $C53C
.C:c552   A2 13      LDX #$13
.C:c554   20 DA CD   JSR $CDDA
.C:c557   CD 3C 0A   CMP $0A3C
.C:c55a   90 E0      BCC $C53C
.C:c55c   60         RTS


This waits until the VDC is ready again before the next call to the kernal-stubs at $cdcc or $cdda are done. It also fixes another bug in the VDC with register 30 ($1e) that sometimes tends to write or copy an extra byte. The kernal just writes one byte less and checks if an extra byte has been set by the VDC (by checking registers 18 ($12) and 19 ($13)). If not it will just set it manually (that's what the BCC $C53c are for). This may also be the cause of the strange behavior you're witnessing.

Let me know if this helps. The VDC really is a buggy and quirky little chip, but if you tell it exactly what to do it can produce fantastic results ;-)

The player as well as demo-files are both linked in the original post on Lemon:

http://noname.c64.org/csdb/release/download.php?id=118874

http://www.megaupload.com/?d=TEEZ58TC

The player is included in the megaupload-archive as well.
Haven't tried this myself yet, but looks pretty impressive...

I came upon this thread yesterday, while trying to understand interlace VDC. I've used interlace in the past, but never really understood HOW the modes worked, I just had some value-tables from a magazine that created different resolutions and just used these.

I'm wondering why the original (non-interlace) VDC-values for registers 4 and 5 are $20/$00 for NTSC and $27/$00 for PAL. According to "Mapping the C128" this comes out to 264 scan lines for NTSC and 320 for PAL - 33*8 / 40*8. Following Hydrophilic's earlier posts this shouldn't be right, since this would come out to 528 (264*2) lines for NTSC and 640 (320*2) for PAL, while the standards call for 525/625 lines respectively.

Do I miss something? Or do the original VDC settings just "bend" the standards a little? I could understand 528 lines for NTSC in that case, but why not use 39 for PAL which would come out to a much closer 624 lines?

Once I get a grip of this I'd like to go back into my old programs to tweak ther interlace-resolutions for more compatibility.

Quote from: Hydrophilic on January 18, 2011, 10:49 AM
Oh, tokra, are you using PAL or an NTSC machine?  Anyway, thanks again for your feedback!

I'm using a PAL-machine. Do you think something like the Media Player could work on the VDC chip as well? I know accessing it through the registers is very cumbersome, but maybe the 2 Mhz-mode would alleviate that.

Quote from: Hydrophilic on January 14, 2011, 12:17 PM
So if I can make a request, could you let me know if you try it, and what setup you used (VICE, real NTSC, real PAL, C1581, uIEC, CMD HD, etc.) Thanks again!

I was trying this on my C128D with UIEC (but NO Jiffy DOS). I think I got about 1 fps out of it. Would a faster drive produce more fps? Maybe you can utilize REUs? Using DMA-access they are blazingly fast.

I'm pretty sure both are the same adapter, they look completely alike. Also judging by http://sites.google.com/site/h2obsession/CBM/C128/rgbi-s-video you will need to build something extra to get 16 colors out of it. I read the latest Commdore Free magazine with Allain Barstows posts, and it looks like that's exactly what he's doing: taking those boards and adding the extra-colors. So you have two options right now: Buy the 8 color version and do the conversion yourself as noted in the link above or wait for Allain's much improved boxed version. I'd go for the latter option myself. But since my 1901 is still running fine, I'm in no real hurry :-)

If 8 colors are enough http://sites.google.com/site/h2obsession/CBM/C128/rgb-conversion seems the easiest solution. This is probably the same converter as on arcadeshop.de but it can be found for $23.99 on http://www.arcademvs.com/ARCADE_ACESSERIOR.htm as well. The other adapter shown there just above this one also looks interesting. For $49.99 it converts to VGA.

But I would just LOVE a simple solution as well: A cable from the C128 40- and 80-column ports to VGA with a switch in the middle. Oh, and support for interlaced modes like 640x720 or 720x700 would be nice as well

Are you maybe in the wrong memory bank after the copy routine? Or do you perhaps overwrite the copying routine itself accidently in the copy process? I had this happen myself one time.

You could also try using PUCRUNCH on a PC to create a neat, packed executable. It creates exactly what you want (a RUN-able executable) and also uses LZH to compress it. Give it a try:

http://www.cs.tut.fi/~albert/Dev/pucrunch/

Scroll all the way down to find documentation and download links.

You can download a clone of the software here:

http://www.c128.net/infos/gb128info.htm

The "hardware" part really only was the update to 64K RAM. Apparantly Combo used a specialized way to do this: Since the VDC-RAM isn't socketed mostly, but the VDC chip is, you had to remove the VDC chip, put the board in its place and put your VDC chip on the board.

Later when the 128DCR came out Combo sold a software-only version, since the computer already had the 64K VDC.

The 256 or 65000 colors are pretty close to a lie I think. It's possible to get some strange colors on the Commodore 1901 Monitor if you shift the picture to the right (or using the VDC registes to do this I think). But I haven't seen any useful implementation of this. And from what I know about the Graphic Booster it only does this by dithering and interlace. Certainly NO special hardware that only Graphic Booster had.

QuoteI'll take a look on this at the Bunkerparty next week. Nice to see such fine stuff. But I fear  I have no time to wait for 2 weeks for a fractal. With my SuperCPU it would probably take only one day but this is also a very long time for one pic.

You can save in between calculation of a picture, back then I only had it calculate during the night.
I've just found an updated version of the disk in my archives. It has a 1084-version of the Paint Preview program for GEOS and obviously I fixed a bug that would only display 640x716 instead of 640x720. I've uploaded the updated disc here:

http://www.tokra.de/c128/64kvdcdisk.d64

As far as I can see BASIC8 only supports "virtual" resolutions and not the modes that GRAPHIC BOOSTER offers. GRAPHIC BOOSTER always was a "dream product" for me back in the day, but I was never able to afford it. By devouring the german "128er" special magazines that had a printed a VDC-register-table I was able to get the higher VDC-resolutions working and I wrote a few programs for it, culminating in adapting an existing BASIC-extension to the res 720x700 and a GEOS128 program that can show a FULL GeoPaint picture on the 1901 monitor in 640x720 res. To demonstrate the high resolution I also made a 720x700 fractal program (taking 2 weeks calculating time for 1 picture in BASIC). I made a "64K VDC Tooldisk" out of my efforts back then which I found on the internet just recently on a lucky search. I have no idea how it got there anymore, but the net obviously never forgets....

http://www.tokra.de/c128/64kvdcdisk.d64
Note: Updated link for new version

All the programs and documentation are in german. The best start otherwise would be just to load "64k fensterrose" to see how the BASIC-extension works. If there's any interest in the programs, I'll gladly be of help and maybe hack together an english short manual for it. Final note: Don't try this on an emulator, the VDC emulation isn't good enough for it. I'm using the Commodore 1901 - a great monitor that is still working after 24 years!