Looking for C128 Specialist as Mentor
in [Commodore]
|
Prev: looking for scroll routine
Next: geoLink 1.01 released
From: Payton Byrd on 26 Apr 2010 10:50 I'm working on a project that is long overdue in the C= community (no, it's not yet another OS or programming language). What I need help with is dealing with the intricacies of the VDC. I am developing my project in C using CC65, with a few bits of Assembler using CA65 where necessary (so far mostly VDC stuff). While the C128 PRG is pretty good, it's extremely fluffy on the VDC and stops short of good examples right when it's needed most. My current roadblock is a good, solid assembler implementation of using the block-copy feature of the VDC to make a snapshot of the screen from 0000 to 0FFF and place that snapshot into 1000 to 1FFF and then to recover that snapshot back to 0000 (all VDC memory). I have an assembler function written, but since you can't get to the VDC memory with the monitor it's very difficult to validate what I've done is correct. I could use a second set of eyes on my code for both correctness and simply logically to validate my approach. One thing I've also found is that the interwebs are extremely lacking in VDC sample code. Most of what I've seen is a rehash of two articles written "back in the day" that basically cover reading/ writing the registers and using the block-fill command (which is what I've based my block-copy code from). I know there are programs like Zed out there that basically use every trick in the VDC book, but I honestly don't know enough about Assembler or using the monitor to interpret that code into something useful. So, are you up for the challenge and want to be a part of a project that will likely grow some legs and be extremely useful to both 64 and 128 users? If so, please drop me an email to plbyrd at gmail dot com. If you just want to help out with an example of using block-copy then please by all means post it here for everyone to benefit from. Thanks, Payton Byrd
From: Vanessa Ezekowitz on 26 Apr 2010 16:05 On Mon, 26 Apr 2010 07:50:40 -0700 (PDT) Payton Byrd <plbyrd(a)gmail.com> wrote: > I'm working on a project that is long overdue in the C= community (no, > it's not yet another OS or programming language). What I need help > with is dealing with the intricacies of the VDC. I am developing my > project in C using CC65, with a few bits of Assembler using CA65 where > necessary (so far mostly VDC stuff). The VDC's block copy runs asynchronously from the 8502, so you can start a block copy and then go off and do something else while the copy runs inside the VDC. The code below is a slight adaptation of what Modplay 128 used to copy instrument effect information from an off-screen memory area onto the visible display during playback of a song, and takes advantage of this property of the VDC. vdcreg = $d600 vdcdata = $d601 ldy #19 ; Set the target address sty vdcreg lda TARGET_LOW sta vdcdata dey ; (selects register 18) sty vdcreg lda TARGET_HIGH sta vdcdata lda #128 ; Request block copy mode ldy #24 jsr writereg ; See note [1] ldy #33 ; Set source address sty vdcreg lda SOURCE-LOW sta vdcdata dey ; (selects register 32.) sty vdcreg lda SOURCE_HIGH sta vdcdata ldy #30 ; Set copy length and start the transfer sty vdcreg lda NUM_BYTES ; Number of bytes to copy, minus 1 (255 = copy 256 bytes) sta vdcdata rts writereg ; Standard write-VDC-register routine sty vdcreg wr bit vdcreg bpl wr sta vdcdata rts To make longer copies, you would do something like this: 1. Run the above routine once, with your initial source and target addresses and 256-byte block length. 2. Increment the SOURCE address by 256, and store it in registers 32/33 as before. 3. Set the block length in register 30 to 255 as before and the copy will start. Repeat from step 2 until the entire range is copied. Don't touch the values in registers 18/19 after you've done step 1 - the VDC will manage your target address for you after the first pass of this extended routine. Since in this case you wanted sixteen 256 byte blocks, you'd just execute step 1 once, and then do steps 2 and 3 fifteen times in a short loop, perhaps using the .X index as your counter as in any typical loop. Hope this helps. [1] Usually you don't need the "writereg" routine, as you can see here. You only need to use that routine when the operation you've done last will tie up the VDC, as with a block copy or block-write, or if you've just done a series of several successive writes to the video RAM. If you try to hit the VDC while it's busy copying, it will ignore you. -- "There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves." http://starbase.globalpc.net/~ezekowitz Vanessa E. <vanDEesLEsaTEezTHekISowitz(a)gmail.com> (Delete the obvious to email me) --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Payton Byrd on 26 Apr 2010 16:51 On Apr 26, 3:05 pm, Vanessa Ezekowitz <vanessaezekow...(a)gmail.com> wrote: > On Mon, 26 Apr 2010 07:50:40 -0700 (PDT) > > Payton Byrd <plb...(a)gmail.com> wrote: > > I'm working on a project that is long overdue in the C= community (no, > > it's not yet another OS or programming language). What I need help > > with is dealing with the intricacies of the VDC. I am developing my > > project in C using CC65, with a few bits of Assembler using CA65 where > > necessary (so far mostly VDC stuff). > > The VDC's block copy runs asynchronously from the 8502, so you can start a block copy and then go off and do something else while the copy runs inside the VDC. The code below is a slight adaptation of what Modplay 128 used to copy instrument effect information from an off-screen memory area onto the visible display during playback of a song, and takes advantage of this property of the VDC. > > vdcreg = $d600 > vdcdata = $d601 > > ldy #19 ; Set the target address > sty vdcreg > lda TARGET_LOW > sta vdcdata > dey ; (selects register 18) > sty vdcreg > lda TARGET_HIGH > sta vdcdata > > lda #128 ; Request block copy mode > ldy #24 > jsr writereg ; See note [1] > > ldy #33 ; Set source address > sty vdcreg > lda SOURCE-LOW > sta vdcdata > dey ; (selects register 32.) > sty vdcreg > lda SOURCE_HIGH > sta vdcdata > > ldy #30 ; Set copy length and start the transfer > sty vdcreg > lda NUM_BYTES ; Number of bytes to copy, minus 1 (255 = copy 256 bytes) > sta vdcdata > rts > > writereg ; Standard write-VDC-register routine > sty vdcreg > > wr > bit vdcreg > bpl wr > sta vdcdata > rts > > To make longer copies, you would do something like this: > > 1. Run the above routine once, with your initial source and target addresses and 256-byte block length. > 2. Increment the SOURCE address by 256, and store it in registers 32/33 as before. > 3. Set the block length in register 30 to 255 as before and the copy will start. > > Repeat from step 2 until the entire range is copied. Don't touch the values in registers 18/19 after you've done step 1 - the VDC will manage your target address for you after the first pass of this extended routine. > > Since in this case you wanted sixteen 256 byte blocks, you'd just execute step 1 once, and then do steps 2 and 3 fifteen times in a short loop, perhaps using the .X index as your counter as in any typical loop. > > Hope this helps. > > [1] Usually you don't need the "writereg" routine, as you can see here. You only need to use that routine when the operation you've done last will tie up the VDC, as with a block copy or block-write, or if you've just done a series of several successive writes to the video RAM. If you try to hit the VDC while it's busy copying, it will ignore you. > > -- > "There are some things in life worth obsessing over. Most > things aren't, and when you learn that, life improves."http://starbase.globalpc.net/~ezekowitz > Vanessa E. <vanDEesLEsaTEezTHekISow...(a)gmail.com> > (Delete the obvious to email me) > > --- news://freenews.netfront.net/ - complaints: n...(a)netfront.net --- Thank you for the code! I'll give it a try when I get home and let you know how it goes.
From: Payton Byrd on 26 Apr 2010 18:50 On Apr 26, 3:05 pm, Vanessa Ezekowitz <vanessaezekow...(a)gmail.com> wrote: > On Mon, 26 Apr 2010 07:50:40 -0700 (PDT) > > Payton Byrd <plb...(a)gmail.com> wrote: > > I'm working on a project that is long overdue in the C= community (no, > > it's not yet another OS or programming language). What I need help > > with is dealing with the intricacies of the VDC. I am developing my > > project in C using CC65, with a few bits of Assembler using CA65 where > > necessary (so far mostly VDC stuff). > > The VDC's block copy runs asynchronously from the 8502, so you can start a block copy and then go off and do something else while the copy runs inside the VDC. The code below is a slight adaptation of what Modplay 128 used to copy instrument effect information from an off-screen memory area onto the visible display during playback of a song, and takes advantage of this property of the VDC. > > vdcreg = $d600 > vdcdata = $d601 > > ldy #19 ; Set the target address > sty vdcreg > lda TARGET_LOW > sta vdcdata > dey ; (selects register 18) > sty vdcreg > lda TARGET_HIGH > sta vdcdata > > lda #128 ; Request block copy mode > ldy #24 > jsr writereg ; See note [1] > > ldy #33 ; Set source address > sty vdcreg > lda SOURCE-LOW > sta vdcdata > dey ; (selects register 32.) > sty vdcreg > lda SOURCE_HIGH > sta vdcdata > > ldy #30 ; Set copy length and start the transfer > sty vdcreg > lda NUM_BYTES ; Number of bytes to copy, minus 1 (255 = copy 256 bytes) > sta vdcdata > rts > > writereg ; Standard write-VDC-register routine > sty vdcreg > > wr > bit vdcreg > bpl wr > sta vdcdata > rts > > To make longer copies, you would do something like this: > > 1. Run the above routine once, with your initial source and target addresses and 256-byte block length. > 2. Increment the SOURCE address by 256, and store it in registers 32/33 as before. > 3. Set the block length in register 30 to 255 as before and the copy will start. > > Repeat from step 2 until the entire range is copied. Don't touch the values in registers 18/19 after you've done step 1 - the VDC will manage your target address for you after the first pass of this extended routine. > > Since in this case you wanted sixteen 256 byte blocks, you'd just execute step 1 once, and then do steps 2 and 3 fifteen times in a short loop, perhaps using the .X index as your counter as in any typical loop. > > Hope this helps. > > [1] Usually you don't need the "writereg" routine, as you can see here. You only need to use that routine when the operation you've done last will tie up the VDC, as with a block copy or block-write, or if you've just done a series of several successive writes to the video RAM. If you try to hit the VDC while it's busy copying, it will ignore you. > > -- > "There are some things in life worth obsessing over. Most > things aren't, and when you learn that, life improves."http://starbase.globalpc.net/~ezekowitz > Vanessa E. <vanDEesLEsaTEezTHekISow...(a)gmail.com> > (Delete the obvious to email me) > > --- news://freenews.netfront.net/ - complaints: n...(a)netfront.net --- THANK YOU, THANK YOU, THANK YOU! This helped me find the bug in my routine. THANK YOU, THANK YOU, THANK YOU!
From: rusure on 27 Apr 2010 00:51
On Apr 26, 8:50 am, Payton Byrd <plb...(a)gmail.com> wrote: > I'm working on a project that is long overdue in the C= community (no, > it's not yet another OS or programming language). What I need help > with is dealing with the intricacies of the VDC. I am developing my > project in C using CC65, with a few bits of Assembler using CA65 where > necessary (so far mostly VDC stuff). > > While the C128 PRG is pretty good, it's extremely fluffy on the VDC > and stops short of good examples right when it's needed most. My > current roadblock is a good, solid assembler implementation of using > the block-copy feature of the VDC to make a snapshot of the screen > from 0000 to 0FFF and place that snapshot into 1000 to 1FFF and then > to recover that snapshot back to 0000 (all VDC memory). I have an > assembler function written, but since you can't get to the VDC memory > with the monitor it's very difficult to validate what I've done is > correct. I could use a second set of eyes on my code for both > correctness and simply logically to validate my approach. > > One thing I've also found is that the interwebs are extremely lacking > in VDC sample code. Most of what I've seen is a rehash of two > articles written "back in the day" that basically cover reading/ > writing the registers and using the block-fill command (which is what > I've based my block-copy code from). I know there are programs like > Zed out there that basically use every trick in the VDC book, but I > honestly don't know enough about Assembler or using the monitor to > interpret that code into something useful. > > So, are you up for the challenge and want to be a part of a project > that will likely grow some legs and be extremely useful to both 64 and > 128 users? If so, please drop me an email to plbyrd at gmail dot > com. If you just want to help out with an example of using block-copy > then please by all means post it here for everyone to benefit from. > > Thanks, > Payton Byrd I find it easier to write and run VDC programs from the 40 column composite screen. After the VDC programs have executed, you switch to the VDC screen to see your results. Somebody may remember 2 COMPUTE GAZETTE programs that augmented the MLM. One was useful for write and using VDC applications. |