warty
KIM-1 User
Posts: 29 
|
Post by warty on Jan 26, 2018 3:37:26 GMT
Hi All, I have been getting back into C= programming the last couple winters. Re-teaching myself assembly, and re-teaching myself VDC fun (which I last did in 1997, which was the last time my Commodores saw the light of day). Anyway, I've been going through all the VDC information I could find from old books, articles, web sites, and forums. I don't have a specific "use" in mind, but if I can remain ambitious, a game of some kind. I'm trying to figure out how to do 640x200 bitmap with 2 colors per 8x2 pixel block. Playing around with VDC registers, I got it basically working on VICE. But on my C128DCR, if I touch register 9 and set it to anything less than 7, I lose the display. For the half second or so I can see it, it looks like something bad is happening to sync. I'm not certain it would happen with a real multi sync monitor. What I have is a Gonbes 8220 unit hooked up to a BIT-C 128. Maybe the combination isn't able to handle sync differences as well as a real multi sync monitor would? So I could use some help here: 1) is there a better set of register settings I could use? I did play around a bit with adjusting vsync, but couldn't hit upon a solution. 2) is this maybe just impossible with a DAC? 3) am I misunderstanding how people achieve more color on VDC? 4) if register 9 is the way to go, do I even need to set register 23 to 2? I've been converting all the articles and chapters I find on VDC and collecting them in an Ebook, and I'll try to write this up as a tutorial article if I can get it working. I understand a lot of material was lost when commodore128.net went offline. "success" shot on VICE:  Code: (note: I don't have a good way to get stuff to my C128 yet, so I have some unnecessary stuff in this code just in case I need some extra space when testing on the C128 (I don't have assembler on it, just the monitor). setAttrSize:
// Character total (vertical). default = $E7
// The number of scan lines, minus one, used to create each character on the screen.
// the setting for R9 below works in VICE, but kills VDC display in my C128DCR
ldx #9
lda #1 // # of pixels per character -1. In bitmap mode, this determines scope of each byte of attribute data.
// as the vertical size gets smaller, the start of drawing space moves up
// for values under 4, probably start of screen will be out of displayable area, unless adjusted
jsr writer
//.byte $ea,$ea,$ea,$ea,$ea,$ea,$ea
// Character displayed (vertical). default = $e8.
// The number of vertical scan lines displayed for each character. This register determines the height of screen characters.
// C128PRG: R23 can be equal to or less than R9. If they are equal, then the displayed part of the character is equal to
// the total character, and the entire character is displayed, with no vertical intercharacter spacing.
ldx #23
lda #2 // # of pixels per character (1-8). In bitmap mode, this determines scope of each byte of attribute data
jsr writer
// set vertical sync position. default = $20
ldx #7
lda #$20
jsr writer
// vertical total adjust. default = $e0
// The number of scan lines added to the end of the display frame for adjustment of the vertical sync rate.
ldx #5
lda #$e0
jsr writer
// Vertical displayed. dfeault = $19
// The number of characters displayed in a frame. This register sets the height of the frame.
// if using half-height color cells, need 50 rows, not 25.
ldx #6
lda #50
jsr writer
|
|
|
|
Post by tokra on Jan 26, 2018 9:18:18 GMT
Don't use VICE for VDC-mode-testing. VDC-emulation is very incomplete in VICE. If you must use emulation I suggest using z64k -> www.z64k.comRegarding the 8x2-mode have a look at VDC Mode Mania -> csdb.dk/release/?id=161195The register setting is done in BASIC there. For 640x480 8x2 interlace look at line 1020 for example. I can see from you example code that you only set register 6. You should set this to 100 instead of 50, since you are not using "half-height color cells", but "quarter-height-color cells". Half-color height would be 8x4. More importantly you need to set register 4 accordingly, since this is the vertical total displayed and responsible for the refresh rate. So, for NTSC you should set this to 131 (132 * 2 = 264), or for PAL to 155 (156 * 2 = 312). I never needed to set register 23. I would leave that out completely. |
|
warty
KIM-1 User
Posts: 29
|
Post by warty on Jan 27, 2018 3:23:10 GMT
Thanks for the quick and accurate response Tokra. It works! I hadn't played with that register, and probably would have not stumbled across the right values. I ended up with these values: R6: 100 ; Vertical displayed. R4: 131 ; Vertical total. R9: 1 ; Character total (vertical). R7: 115 ; vertical sync position. (on my screen, this pretty much centered it. "1" was close, but still too far off for all text/pixels to be visible. By "works" I mean I can see a screen, no sync problems, and colors are banded in 2 pixel high rows. BUT... weirdness with what is actually displayed. Some other kind of problem, I suspect. I am doing a block copy, putting $aa into everything in the 640x200 bitmap, from $0000 for 16k bytes. Then I put the color in, having moved attribute ram to to $3f00 (pretty much just after the bitmap area). I'm currently only filling half the screen with color, but it does appear to be writing the color just fine. But the bitmap data is oddly garbled. On VICE it's what I was expecting to see (I get that VICE isn't a good VDC simulator, I'm just mentioning it so you have an idea of what I thought would appear). On Z64K, it's garbled, but not exactly the same way as on my C128DCR. On the 128, it's garbled in a few ways. Z64K:  C128DCR:  The code for the bitmap data write: ;clear vdc w/block fill
clear: ldx #18 ; set data pointer to 0
lda #0 ; for start of hires
jsr writer
inx
jsr writer
lda #$aa ; set fill byte to 0f, aa, etc, so we have some kind of pattern
jsr write
ldx #24 ; clear bit 7 of
jsr reeder ; register 24 to
and #127 ; select block fill
jsr writer
; 80x25 = 128 pages. 80x50 = 256 pages.
ldy #255 ; clear 64 pages (64*256=16384 bytes to clear)
ldx #30 ; reg 30 is word count
lda #0 ; 0 words=256 bytes
clear1: jsr writer
dey
bne clear1
rts
Z64K is kind of awesome, by the way. The little assembler built into it is very helpful, even easier than the Eclipse plugin CMD-0 to launch in VICE. Especially because it accepts ; comments, not the // style comments. |
|
|
|
Post by tokra on Jan 27, 2018 8:50:38 GMT
Hmm, can you post or uploade the full program? If I find time I could play with that myself. However what you can try already is to set register 36 (DMA-refresh) to 0. The screen below looks like the VDC cannot keep up, and you can gain a little time for the VDC by reducing the DMA-refresh to 0. Oh, and of course you need to set bit 4 of register 28, so the VDC is in 64K-mode. I always keep this handy website-open when VDC-hacking: www.oxyron.de/html/registers_vdc.html |
|
|
|
Post by willymanilly on Jan 27, 2018 19:50:16 GMT
Bit 4 of register 28 is not fully emulated yet when in 16K mode on Z64K. There is a test and some information on VICE's test repository here ==> sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VDC/vdcdump/ Z64K passes 3 out of 4 for the test. I know the fix and it's something on my list to do. I suspect it has something to do for the reason why the screenshots you provided don't match. If you upload any program that has different behavior on Z64K compared to the real thing and you are happy to share, it would very useful for me to improve the VDC emulation. Tokra's images from VDC mode mania and VDC VGA mania are the reasons why I was able to get Z64K's VDC emulation to where it is now.  I'm glad you find the inbuilt assembler useful. You should note though it is incomplete and I know of a few bugs that need to be fixed but for simple programs it is functional. I will release information on all assembler options once I find time to get rid of all the bugs and update the assembler functionality. For now it's a use at your own risk category but in saying that I've been using it for my programs. The latest source code for d030 tester uses the inbuilt Z64K assembler and can give you some hints on what options are available. csdb.dk/release/?id=161586 |
|
warty
KIM-1 User
Posts: 29
|
Post by warty on Jan 31, 2018 3:54:34 GMT
Tokra: getting ever closer I think. That last hint helped a lot. Even though this was a 64k (from start) DCR, it apparently didn't know it had the 64k. At least, that's my interpretation of what happened. Once I set the 64K mode, the color data write routine (on both Z64K and 128DCR) writes differently. On Z64K, it looks like what I thought it would look like. But on both, the little weird curly bits of pixels are gone. I think those were the color data overwriting bitmap data, as the VDC looped back to $0000. That's the good news. The not-so-good news is that the real 128VDC doesn't produce the same results as Z64K. I'm going to play around with drawing some boxes and whatnot, and see what happens, but I did a quick and dirty test of just hitting enter 25-30 times, and watching the screen. If I do that, the top portion of the screen in both Z64k and 128DCR will end up looking (approximately?) the same. So that makes me think something about the block fill routine for the bitmap is not working right on real hardware. I'm attaching the source code in case you have time to look at it. Z64K and then real machine, after running program (sys3072):   same again, after clearing text screen by hitting enter a bunch. The bitmaps now appear to match up.   Source code vdc8x2_write_test_20180130.asm (5.14 KB) |
|
warty
KIM-1 User
Posts: 29
|
Post by warty on Jan 31, 2018 4:00:09 GMT
WillyManilly: I'm just putzing around at this point, but I always like 80 col mode, so I'll probably keep pushing at little things. Unfortunately, I'm also working on turning a bunch of old C-128 and a few C-64 books into nicely formatted ebooks with tested source code, so my "fun" time is a bit scattered at the moment. But if I come up with anything, I'll let you know. Or if there is some testing (light testing! ) I can do for you with Z64K, let me know.
|
|
warty
KIM-1 User
Posts: 29
|
Post by warty on Jan 31, 2018 6:28:39 GMT
Hi Tokra, I figured out the problem with the last version: - I was working off somebody else's program that I had hacked down from its original purpose (color copy C128 40 col screen to 80 col, from an old Transactor issue). It looks like there was a typo in there using reg35 not reg36, and I hadn't paid attention to it. This was in the blank/unblank bit. It probably didn't make much difference, but it wasn't needed and it would have overwritten the refresh rate setting you gave me. - more importantly, due to the unfamiliar structure of that program, I wasn't setting the 64k mode thing before writing all the bit map data, so that part was looping. I cut down the code are re-arranged some calls. Works fine now. Thanks again for helping! I'm putting together what I learned in a kind of VDC Compendium (99% various chapters on VDC from old books, plus some new stuff as I figure it out and can write it up). WillyManilly: It definitely seems like Z64K assumes 64K VDC from the get go. I have no idea if that's correct or reasonable or not, but I think it accounts for the differences in behavior between it and my particular 128DCR. Corrected version of program: vdc8x2_write_test_20180130v2.asm (4.5 KB) |
|
|
|
Post by Pyrofer on Jan 31, 2018 16:04:50 GMT
It's interesting to note that while there is a 64/16k bit in the 128 rom, it's never set to anything other than 16k that I know of!
Even the 64k machines had the rom say they were 16k and you had to manually check by toggling the bit, doing a read/write test to find out if you actually did have 64k installed.
If you burn your own rom you can of course set this bit but as nobody elses machine has it set you need to do the ram test in your own code anyway. It's a pain.
Even MORE frustrating is that when you change the 16/64k setting on the VDC it changes the way the ram is accessed. Who cares? You do if you want to use the existing font!!! The font is copied into VDC ram by the 128 kernal on boot. If you then change it to 64k the data is scrambled and you lose the font.
You have to rerun the system call to the routine that copies the font back into the VDC ram, or manually load in your own font if you want.
Another trick here when testing on emulators is that VICE (For sure, don't know about Z64k) doesn't correctly emulate the need for the ready bit on the VDC. If you don't check for it on vice, it all just works. If you don't check for it on real hardware, loads of stuff breaks.
I also don't think VICE emulates the memory corruption that happens when you set the VDC into 64k mode, so you can have a program that appears to work perfectly on VICE but has corrupted fonts on real hardware.
Never trust VICE for any 128 testing, let alone the VDC stuff.
|
|
|
|
Post by willymanilly on Feb 2, 2018 21:26:07 GMT
Z64K has only 64KB VDC physical ram option. When in 16KB mode via register 28, Z64K simply masks the address with $3fff. A real c128 does not mask the address that simply hence you will witness the behavior that Pyrofer describes above. The actual mapping is detailed in the vdcdump test program I linked to in my previous message. It's on my to do list to fix in Z64K.
Thanks for the source to your program. I will use it as another test program to compare results between my real c128 and Z64K.
I'm currently researching the behaviour of to d030 register and implementing what I find into Z64K. I plan on writing similar test programs for VDC in the near future including timing of the ready bit. The behavior of the ready bit is partly implemented on Z64K but should not be relied on yet
|
|
