80-column interlace

Started by commodorejohn, September 12, 2008, 02:36 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

commodorejohn

Okay, I've been reading through the VDC documentation in Mapping The Commodore 128, and man is it complicated. As I understand it, the VDC, by default, operates in non-interlaced mode, with a character height of eight pixels, but 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 mode? Am I understanding this correctly?

airship

You might want to look at the VDC programming sub-forum above. I don't know if this specific question is answered, but there sure is a bunch of good stuff about programming the VDC. Good luck!
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

hydrophilic

The pixel size of both the VIC and VDC are nowhere near square.  You can make the VDC pixels the same proportion as VIC pixels by either using interlace-and-video mode (then you have 50 tall character screen that KERNAL doesn't support) or you can activate the pixel double-width mode (but then you have a 40 column screen).

With either method, the pixels should have the same aspect ratio as the VIC.  But that's still not square!  In other words, still too tall.  You would have to implement some custom mode for square pixels and unless you have a monitor with very flexible timining, it wouldn't work...

airship

On a similar topic, I just stumbled across the interlaced screen modes in the ZED editor for the first time a couple of weeks back.

80x50?!? I LOVE it! Why couldn't someone have come up with this back in the day? If I tweak the settings on my 1902A a bit, I can't even see the interlace, even with green on black. Sweet.
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

RobertB

Quote from: airship on September 13, 2008, 12:41 AMOn a similar topic, I just stumbled across the interlaced screen modes in the ZED editor for the first time a couple of weeks back.
Interesting, isn't it?  :)
Quote from: airship on September 13, 2008, 12:41 AM
80x50?!? I LOVE it! Why couldn't someone have come up with this back in the day?
ZED was created back in 1993.  Isn't that "back in the day"?  :)
Quote from: airship on September 13, 2008, 12:41 AMIf I tweak the settings on my 1902A a bit, I can't even see the interlace...
On my 20-inch Sears RGB tv/monitor, no matter how much I tweak, the interlace is still there.  If I want to see huge expanses of the article I'm writing in ZED, I go to 50 lines; however, instead of squinting (even at 50 lines on a 20-inch monitor), I go to 27 or 29 lines.

          Truly,
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug

airship

Quote from: RobertB on September 13, 2008, 09:24 AMZED was created back in 1993.  Isn't that "back in the day"?

Nope. 'Back in the Day' officially expired in Sept. 1992, when INFO gasped its last breath. :)

Now, what's the 'secret code' for kicking C128 BASIC into 50-line mode for program editing? Or can't that be done without an M/L support routine?
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

commodorejohn

Well, putting the VDC in 50-line mode is easy enough, but the extra 25 lines are just ignored. According to Mapping The Commodore 128, in order to make it work the way you're thinking, you'd have to put a modified copy of the BASIC ROM (or at least the part containing the screen-editor routines) in RAM and switch out the ROM. Doable, but probably too much of a pain to be worth it.

airship

Quote from: commodorejohn on September 16, 2008, 06:29 AM...you'd have to put a modified copy of the BASIC ROM (or at least the part containing the screen-editor routines) in RAM and switch out the ROM. Doable, but probably too much of a pain to be worth it.

Ooh! Ooh! I just ordered an EPROM programmer! Now all I need is someone to rewrite the screen editor for me! :)
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

hydrophilic

Too busy to write it for you :)  It sounds like a fun project though.  The major problem with the Editor ROM (the $C000~$CFFF region, not really seperate ROM), is that it is hard-coded with a look-up table for screen addresses that is only 25 entries long (lines tall).

With plenty of unused space in the ROM, it should be a trivial matter to add an extended (50 entry*2 bytes=100 bytes) table in ROM and simply change the references in the code.  It seems like only 1 or 2 routines reference the table; also a few routines are hard-coded to limit the value to 25.  I don't have my disassembly on this PC, so I'll check the details later and get back to you.

That's part 1.  Part 2 would be to change CINT, the console init routine so that the VDC is properly set for 50-lines.

Of course the ultimate hack would do the normal 25 line setup and have a routine you could SYS to switch back and forth between normal and interlaced modes.

I got get an EPROM burner someday...

airship

Yes, you need an EPROM burner. In fact, anyone who knows how to create cool stuff for this machine needs one, so the rest of us can profit from your efforts. :)

If it's just a matter of recoding a table and a couple of references, I could probably do that. I could probably even make it work with 25/50 rows without too much trouble, since the routine would be the same except for the tables and limits.

If I live that long, of course...
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

BigDumbDinosaur

QuoteThe major problem with the Editor ROM (the $C000~$CFFF region, not really seperate ROM), is that it is hard-coded with a look-up table for screen addresses that is only 25 entries long (lines tall).

If I were going to rejigger the editor ROM I'd get rid of all the 40 column crap.   :)  That would greatly speed up the rate at which the 80 column side of things would work.
x86?  We ain't got no x86.  We don't need no stinking x86!

airship

Quote from: BigDumbDinosaur on September 18, 2008, 01:54 AMIf I were going to rejigger the editor ROM I'd get rid of all the 40 column crap.   :)  That would greatly speed up the rate at which the 80 column side of things would work.

Accepted. I've put this on your 'To Do' list, BDD. :)
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

hydrophilic

OK, I've completed my research.  The line-address tables are importantly accessed from the following locations:
$c15e (lo)
$c16b (hi)
$c44c (lo)
$c452 (hi)
(another routine for VIC also refernces the tables, but not important)

The existing tables include a $400 offset and the VDC addresses are calc'd by masking the high-byte and doubling the value.  For 50 lines, you need to remove the offset from the new tables and change the mask value at the following locations:

$c16b (3 -> 7)
$c455 (3 -> 7)
$c186 (7 -> $f)
$c488 (7 -> $f)
$c521 (7 -> $f)

You'll need 100 bytes to put the two 50-byte tables (low bytes, high bytes).  It looks like the best place is between the '86 patch code and the '86 copyright message at $CF1C ~ $CF7F (only 2 bytes to spare!)

The 80 column editor will need to know there are now max 50 lines so change two bytes in the editor initialization data, starting at $ce8e:

offset 4 ($ce92), 24 -> 49
offset 13 ($ce9b), 24 -> 49

I thought several places in ROM routines would also need to be changed from 24/25 to 49/50, but those routines read from the data set during initialization; the above does it!

Of course the attributes will need to move 'up' in VDC RAM.  $1000 is a good starting address.  This is setup (for edtor not the chip) during initialization of 'vm4'.  Change the code at $c0b2 to use $10 instead of 8.

The VDC registers will need to be initialized properly.  The initialization data is stored in a table in the KERNAL ROM at $E2F8.  I haven't tested these values so you may want to experiment here...

offset 7 (VDC reg 3) $49 -> $89 (v sync width)
offset 9 (VDC reg 4) -> 64 (vertical char total - 1)
offset 11 (VDC reg 5) -> 4 (I think, docs aren't clear... or leave it 0)
offset 13 (VDC reg 6) -> 50 (vertical char displayed)
offset 15 (VDC reg 7) -> 57 (just a guess, for screen centering)
offset 17 (VDC reg 8) -> 3 (interlace sync & video)
offset 33 (VDC reg ?) 8 -> $10 (attribute start address hi)

These are for NTSC.  PAL users have fun!

I also discovered a problem I hadn't thought about.  Line links!  There is a table of line links in common RAM (page 3).  These get swapped with a region in page 10 ($0axx) during 40/80 mode change.  Well you could find some extra room in page 10 but in page 3 you can't expand the table without moving everything else around.

So it sounds like a no-go but...

Tab-stop setting are in an adjacent table and also get swapped on mode switching.  So just liberate 3 bytes.  Who cares about tab stops anyway? :)  Seriously, they'll function fine on 40 column screen, and 70% of the 80-column screen width.

So the final changes are to reduce the line-wrap table start address by 3 bytes (from $35e to $35b) in the following places:
$ca36 (this uses adress-1 so make it $35a)
$cb40~4a (this is the swapper code, 4 references here)
$cb79
$cb8a
$cb8d
This makes for a 7-byte table which can handle 56 lines.  So change $ca34(?) from 4 to 7.

There you have it.  Be sure to do this with an EPROM so you can try again when you discover something I forgot!

airship

Wow! That's fantastic! Great work, man.

Now all I need are BDD's improvements via removal of the 40-column screen support. :)
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine