VDC Questions

[commodorejohn]

Okay, I've been reading through the VDC documentation in Mapping The Commodore 128, and man is it complicated. I think I've got most of it figured out, but I still have a couple questions:

• As I understand it, the VDC, by default, operates in non-interlaced mode, with a character height of eight pixels, so it's running in 640x200, rather like CGA mode 2. But this means that the pixels are vertically stretched, or rather horizontally compressed, and the only way to get normal, square pixels (or rather, to appear to have them) is to turn on interlaced sync mode. Am I understanding this correctly?
• Speaking of interlaced, plain interlaced mode (mode 1) seems to function exactly like non-interlaced mode, only with the annoying jitter. Is there some hidden and surprising function of this that I've missed, or is it just utterly useless?
• I understand about setting the register number and waiting until the VDC is ready before writing to a register, but what about the memory-write register ($1F?) Is it possible to write the register-select value, wait for the ready signal, and then write a stream of values? In other words, could the REU potentially be used to transfer data to the VDC quickly?

[hydrophilic]

1.  You could also use double-width pixel mode.  In either case, the pixels still won't be square (more elaborate response in your original post)

2. Yes, rather useless unless your monitor doesn't flicker (LCDs)

3. This is a very limited possibility.  With the default settings, you can safely write only a few values consecutively before the VDC starts "dropping" data.  If you set the RAM refresh register to the minimal value (0), it's reported you can safely write 8 bytes at a time; AFAIK, this is tested only with the CPU doing the writing, not an REU.

[commodorejohn]

1. Well, I wasn't meaning absolutely square pixels, just the standard square-ish ones. But anyway, you can't have normally-proportioned pixels and a higher-resolution screen than the VIC without faking it via interlaced sync mode, then?

2. So, if your monitor doesn't flicker...what? It would then be exactly the same as non-interlaced mode, right? Hm.

3. Well, 8 bytes with the CPU doing the writing is probably going to be closer to the 20-30ish range with DMA, if I recall correctly, but I guess I'll have to test this myself. Bummer, though, I was hoping that would make things a lot easier. Now, what do I look for when it starts "dropping" data? Things just don't get written, or does it write junk values?

[hydrophilic]

1. Sounds about right

2. Not exactly the same.  The image is more dense.  A character is then 8x16 pixels (of course the resolution doesn't increase because the same pattern is repeated on the second field).  You should notice this no matter type of monitor you have.  In normal mode the rasters, to me, seem 'fat' with a minute black gap between each one, while interlace(either type) seems to have thinner rasters with no gap between them.  With a stable raster IRQ routine, the possibility exists to change settengs between fields for some useful(?) effects...

3. I don't know what happens.  Never tried it myself, only reporting what I've read.  I believe it was in an issue of C=Hacking... is I recall, the theory is the 8563 has an internal buffer.  8 bytes sounds reasonable.  So using an REU might not improve things.  I, for one, would be interested in the results of such experiments.  It would be nice to have some support of the theory or you can prove it wrong!  Also as I recall, 8 bytes was the reliable number when using the minimum DRAM setting.  I inferred from the article that many bytes could be written when the raster was in the border area, but without a raster register (like VIC $D012), it's hard to know when that is.

[commodorejohn]

Well, I haven't had time to do a full test of my idea, but I was able to write 256 bytes consecutively in plain old assembly without having to reset the register. Further bulletins as events warrant.

[commodorejohn]

Alright, I finally found the time to test my idea. And good news, it wrote a full 700 bytes before dropping the rest, which means that a full text screen (minus attributes) could be copied in three REU transfers. My 128 has an 8563R9, but here's the code I used, so people can test it on other versions of the VDC:

Code Select Expand

     .org $1300 ; my suggested starting point, at any rate
     ; prep one byte of screen data
     lda #$2e
     sta $1400
     ; transfer to REU memory
     lda #$00
     sta $df02
     sta $df04
     sta $df05
     sta $df06
     sta $df08
     lda #$14
     sta $df03
     lda #$01
     sta $df07
     lda #$C0
     sta $df0a
     lda #$a0
     sta $df01
     ; prep the VDC for the write
     lda #$00
     ldx #$12
     jsr $cdcc
     inx
     jsr $cdcc
     ldx #$24 ; set DRAM refresh to 0
     lda #$00 ; for easy testing with different refresh rates
     jsr $cdcc
     ; set the REU to write this byte 2000 times to $d601
     lda #$d0
     sta $df07
     lda #$07
     sta $df08
     lda #$01
     sta $df02
     lda #$d6
     sta $df03
     lda #$a1 ; to initiate DMA once the VDC is ready
     ; set up the VDC for the transfer
     ldx #$1f
     stx $d600
wait bit $d600
     bpl wait
     ; initiate the transfer
     sta $df01
loop bmi loop ; now loop so we can see the results

I used a couple labels, but it's easy enough to just punch this into the monitor like I did.

[hydrophilic]

Wow 700 bytes!  I don't have an REU to try your code, but now I'm curious what I can manage reliably (pure CPU work obviously).  I guess this means it's time to finish my RGBI converter   Speaking of which, anybody know a source for cassette-port connectors?

[commodorejohn]

I have an extra cassette-port connector lying around; PM me and we'll work out the shipping details.

P.S. how easy is an RGBI converter to build, anyway? I would expect it's a lot simpler than a composite->VGA converter...

[hydrophilic]

I have an extra cassette-port connector lying around; PM me and we'll work out the shipping details.

Awesome!

P.S. how easy is an RGBI converter to build, anyway?

Well, it's trivial if you start with an RGB converter!  The one I'm working on outputs to composite(crap) and S-Video(fantastic).  See this topic.  Another method is RGB(I) to VGA.  In that case see this topic

[commodorejohn]

Well, I have another VDC-related question, and it's a rather big one:

HOW IN THE HELL DO THE DISPLAY-RESIZING REGISTERS WORK!?

It doesn't seem like it should be that complicated, but even a simple attempt to switch to a 12-line 16-pixel-tall-character setup results in lunatic vertical hold issues. I must be grossly misunderstanding the explanation of these registers in Mapping The Commodore 128, but I can't figure out where my mistake(s) lie(s):

Code Select Expand

lda #$01 ; set the background color so we can see changes in the display area
ldx #$1a
jsr $cdcc
lda #$0f ; set the screen to 16 rows total
ldx #$04
jsr $cdcc
lda #$0f ; set the character height to 16 pixels
ldx #$09
jsr $cdcc
lda #$08 ; set for 8 lines extra to bring us to NTSC 264 lines
ldx #$05
jsr $cdcc
lda #$0c ; set to use 12 lines for display
ldx #$06
jsr $cdcc
rts
All I get is vertical-hold problems. What am I misunderstanding here?

[hydrophilic]

I think you need to set the vertical sync position, register 7.  My formula for this register is (vertical total - vertical disp) / 2 + vertical disp.  So try (16-12)/2 + 16 = 18.  I believe the default value is 28 and since you have less than 28 total, vertical sync is never generated!  Hence a rolling display.

FYI, the correct #rasters should be 262.5 for interlace.  For non-interlace you should use 262 or 263.  I believe you got 264 from the default configuration which generates a slightly slow rate of 59.65 Hz (according to my calculations, I don't have an o'scope to test). Also according to calculations, 262 rasters should generate 60.1 Hz, while 263 rasters should generate 59.9 Hz.

PS, I use a similar/corresponding formula for horizontal sync position.

[Shaun_CCC(UK)]

I've got a VDC question: what is the max resolution the VDC chip can output without modification? I know interlaced at 640 x 400, can it go any higher than this?

Regards,

Shaun.

[RobertB]

...what is the max resolution the VDC chip can output without modification? I know interlaced at 640 x 400, can it go any higher than this?

Ack!  I don't have my Basic 8 manual in front of me, but yes, it can go higher than 640 x 400.  I remember it being somewhere north of 704 x ?.  I can check when I return to California.

            Back from a fine dinner at the Seattle waterfront,
            Robert Bernardo
            Fresno Commodore User Group
            http://videocam.net.au/fcug
            July 24-25 Commodore Vegas Expo v6 - http://www.portcommodore.com/commvex

[wte]

The max resolution depends on the graphic mode (monochrome/color) and ram (64k required for more than 640x200). Furthermore you need the 1901 Monitor for some modes (the 1084 sucks).

The following pic is from the Graphic Booster graphic extension.

Regards WTE

[tokra]

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!

[commodorejohn]

Hmm, I'll have to take a look at that. I do want to finish the VDC documentation I was working on a while back, but I'd need to get my 128 set up again...

[wte]

http://www.tokra.de/c128/C108.D64

I'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.

And yes, it's a shame that the VDC support of VICE sucks.

Regards WTE

[commodorejohn]

Eh, VICE's VDC support is adequate for most VDC software, as long as it doesn't try to push the limits and play around with unconvential settings. Problem is, most of the VDC software worth looking at is the stuff that pushes the limits...

[tokra]

I'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

[wte]

Thanks for the new version.

[wte]

Bunkerparty is over - a lot of maniac people  met Dr. Fred, Edna, Ted, and Ed.
Nice fractals on the disk - Thank's again!

[RobertB]

     Ooo, are there photographs of the event?

            Still in Aberdeen, Scotland,
            Robert Bernardo
            Fresno Commodore User Group
            http://videocam.net.au/fcug
            July 24-25 Commodore Vegas Expo 2010 - http://www.portcommodore.com/commvex

[wte]

Look here: http://www.commodore128.org/index.php?topic=3443.0