Author Topic: Compute!'s 128 Programmer's Guide - ERRORS  (Read 1129 times)

0 Members and 1 Guest are viewing this topic.

XmikeX

  • Guest
Compute!'s 128 Programmer's Guide - ERRORS
« on: December 11, 2010, 10:11 AM »
The other day I noticed the following errors in Compute!'s 128 Programmer's Guide ( ISBN 0-87455-031-9 ).  These have likely been discovered long ago, but they are new to me and I thought it might be worthwhile to relate them here.

Chapter 2 - Page 165 -- line 60...  ... SIN(X*/32)) .. what?  new math? ..  probably is X*pi-symbol/32 .. (I'm assuming their print shop or other contractor couldn't handle the C= pi symbol.)

Chapter 2 - Page 167 -- line 105 should be ... 105 SYS AD,31,AC : SYS AD,31,AC
  -- Now it works!  ..(works IF you input the short ml code described earlier in the chapter.)
  -- (EDIT : Add the following .. 5 PRINT CHR$(142)  .. to make sure you are in the proper charset from the start.)

This last program (on Page 167) described, as follows:
""
Oversize Characters
A normal 80-column screen contains 25 lines of characters; each line is 8 bytes tall. As mentioned earlier, each 80-column character definition uses 16 bytes of memory, but 8 of these bytes are not used. This program displays double-height characters which use all 16 bytes of each character definition.
""
as seen here :
http://www.bombjack.org/commodore/
http://www.bombjack.org/commodore/books/pdf/Compute%27s_128_Programmer%27s_Guide.zip

VICE might be in trouble on this one.  From data I've been able to extract out of people with an eye on emulators, everything in VICE x128 VDC emu is coded around 8 pixels per char.  It is "known" that the VDC uses character sets with 16 bytes per char for 16 pixel height.  (This is used by the oversize program above, and works in VICE.)  However, it is not generally known that VDC can also do 32-pixel high chars, and once you select > 16 the VDC will naturally use a different character set layout.

The Question now is : Can VICE x128 can do 32-pixel high chars?
I'll have to learn a little more before I try it myself. =)

XmX
« Last Edit: December 11, 2010, 11:31 PM by XmikeX »

Offline Hydrophilic

  • 128D user
  • *******
  • Posts: 1429
  • Reputation: 233
  • Gender: Male
    • View Profile
    • H2Obsesson
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #1 on: March 22, 2014, 04:53 AM »
I know this an old post, but I thought it was interesting -- at least the last part!  There are a bunch of errors in Commodore's P.R.G. in particular involving the VDC.  I once thought about posting on that, but if I started documenting the errors in their book then I would be busy for quite some time!
 
Anyway, I have never heard of VDC producing characters greater than 16 rasters tall.  If it actually works that would be an interesting undocumented feature.  However it doesn't sound like a usefull feature!  If the designers want to sneak in features, they should be cool and useful :)  Maybe I am just not thinking creatively?  Imagine the possibilities of 30-raster tall characters!  :-\
 
Does anyone have any more info about this?
I'm kupo for kupo nuts!

Offline VDC8x2

  • PET user
  • ***
  • Posts: 74
  • Country: us
  • Reputation: 2
    • View Profile
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #2 on: March 22, 2014, 02:57 PM »
think 32 raster tall char scroll.

I think if you go 32 rasters tall the the char set takes up 16k instead of the 8k in vdc ram
« Last Edit: March 22, 2014, 03:03 PM by VDC8x2 »

Offline gsteemso

  • VIC 20 user
  • ****
  • Posts: 106
  • Country: us
  • Reputation: 24
  • Gender: Male
  • C128 & Mac user
    • View Profile
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #3 on: March 25, 2014, 01:32 PM »
I don’t recall where I saw it, but there was a game programmer who used 32-raster characters, one unique character per cell, to cover the entire screen. By doing that, it became possible to do vertical-motion animations with sequential writes to VDC character definition RAM, taking advantage of the automatic address increment, instead of having to set a new address for every write. It was apparently a LOT faster for stuff like those old games where you shoot up at waves of aliens that march ominously down the screen, dropping bombs on you as they go.
The world’s only gsteemso

Offline smf

  • PET user
  • ***
  • Posts: 84
  • Reputation: 2
    • View Profile
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #4 on: March 26, 2014, 08:56 PM »
Anyway, I have never heard of VDC producing characters greater than 16 rasters tall.  If it actually works that would be an interesting undocumented feature.  However it doesn't sound like a usefull feature!  If the designers want to sneak in features, they should be cool and useful :)

Most undocumented features are usually side effects and not sneaked in by the designers at all. There are exceptions, the hitachi 6309 is the most famous (it started as a licensed 6809 clone but hitachi added so many good features that Motorola told them they couldn't tell anyone about them).

Offline Hydrophilic

  • 128D user
  • *******
  • Posts: 1429
  • Reputation: 233
  • Gender: Male
    • View Profile
    • H2Obsesson
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #5 on: March 28, 2014, 03:51 AM »
Yeah, smf, I agree that many "features" that sneak into a working product were not desgined at all!  There are numerous VIC-II hacks that seem imposible to have been designed... so it does not suprise me that secret "features" are possible with VDC either...
 
And of course, thanks to gsteemso about info on 32-segment characters (for lack of better name)... does anybody have working code that demonstrates this?  If I found a magazine article I might type it in (if not very long), but of course it would be much more convienent if ANYBODY has actual working code ?  Please???
 
From my experience, it is slow to update VDC bitmap mode, but updating standard (8x8) char mode is plenty fast!  In other words, I really don't see advantage of using 8x16, or as this thread implies 8x32, character mode...
 
Well I hope to get "standard" 8x8 text mode "video" released this year... think yucky Spectrum blockiness... but still it would be intersting to learn about 8x32 characters.  For example, the "standard" characters waste 8 bytes each!  My CBM encoder can do any cell size, but 8x8 looks bad, and 8x16 looks really REALLY bad.  I haven't tried 8x32 (because I don't know the details), but I imagine it would look really REALLY REALLY bad!
 
So if anybody has some working code with this mythical 8x32 mode, then please post... thanks!
I'm kupo for kupo nuts!

Offline tokra

  • VIC 20 user
  • ****
  • Posts: 150
  • Country: de
  • Reputation: 11
  • Gender: Male
    • View Profile
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #6 on: March 28, 2014, 12:36 PM »
Ok, I've just tried this 32 pixel char-height mode. Works as expected. You really do have 8 pixel wide 32 pixel tall chars then. Of course the font is completely wrong and I suspect 8x32 chars would not be very readable in the first place. However you may be able to combine this with double-pixel mode and then have something more readable (if you are willing to create a font for this).

One quirk I noticed is that bit 5 of register 28 is being ignored. So you can only place the character-defintions in 16K steps. A full double font of 32 pixel tall chars would take up all 16K (512 x 32 bytes), but you can probably use just one font and place video and attribute-RAM after $2000 in VDC-RAM. I did not test that far, only wanted to confirm the mode would work in principle.

Offline VDC8x2

  • PET user
  • ***
  • Posts: 74
  • Country: us
  • Reputation: 2
    • View Profile
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #7 on: March 28, 2014, 04:40 PM »
Quote
So you can only place the character-defintions in 16K steps

would make sense since the char ram it needs is doubled at 32 raster char mode.

Offline Hydrophilic

  • 128D user
  • *******
  • Posts: 1429
  • Reputation: 233
  • Gender: Male
    • View Profile
    • H2Obsesson
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #8 on: March 29, 2014, 06:05 PM »
It would be more useful if it would half the font size when raster height is 8 or less... I can't think of any software that uses 16-pixel tall font.  The closest thing is ZED interlace mode which uses 9-pixel tall characters.... the font is really the same standard 8-pixel tall font, but 1 extra blank raster is used to make the text more legible (i.e., more space between rows).  Well, I think Tokra released IBM text mode emulation that uses 9x11 font?  That was more a proof-of-concept than actual working software, as I recall.
 
Thanks for experimenting with real hardware Tokra.  I'll update my CBM Encoder to allow 32-pixel tall chars, and then see what kind of garbage shows up on the VDC :)  If I understand correctly, if you left the "font register" at the default setting then it would map "normal" characters at $0000 and "alternate" characters at $2000... so if the text screen only used the alternate set, you could keep the default memory layout? 
 
I don't suppose you made any notes on the register settings?  Those registers always confuse me, some use exact value, some need value +1 and some need value -1, and I'm pretty sure there are errors in the descriptions provided by CBM's C128 P.R.G.
Anyway, based on the initial values set by KERNAL along with my incomplete understanding of VDC, the NTSC settings would be:
 
Register $04: 07 (was 32 = $20 -> 33*8 = 264 rasters) results in 8*32 = 256 base rasters
Register $05: 07 (was 0) results in 256+7 = 263 total rasters
Register $06: 06 (was 25 = $19 -> 25*8 = 200 rasters) results in 6*32 = 192 working rasters
Register $07: 07 (was 29 = $1d -> [32+1+25]/2 ) result of [7+1+6]/2
Register $09: 31 = $1f (was 7)
Register $0b: 31 = $1f (was 7)
Register $17: 32 = $20 (was 8 ) ... um, docs say only bits 0~4
Register $1d: 31 = $1f (was 7)
 
and the PAL settings would be:
Register $04: 08 (was 38 = $26 -> 39*8 = 312 rasters) results in 9*32 = 288 base rasters
Register $05: 24 = $18 (was 0) results in 288+24 = 312 total rasters
Register $06: 06 (was 25 = $19 -> 25*8 = 200 rasters) results in 6*32 = 192 working rasters
Register $07: 07 (was 32 = $20 -> [38+1+25]/2 ) result of [8+1+6]/2
Register $09: 31 = $1f (was 7)
Register $0b: 31 = $1f (was 7)
Register $17: 32 = $20 (was 8 ) ... um, docs say only bits 0~4
Register $1d: 31 = $1f (was 7)
 
Now that I'm reviewing VDC docs, I see that many registers allow 5 bits which does imply it could handle at least 31-pixel tall characters.  The strange thing is register $17 which I believe needs a value of 32, which won't fit in 5 bits.  Of course that register may be 6 bits wide and the documentation is wrong.
 
Edit
So I wrote little program in MONITOR to build a dummy font... it just expands the standard font (lower-case version) to 32-pixels tall.  Then I wanted to see how VICE messed it up.  To my surprise VICE 2.1 (and presumably later) will display 32-pixel tall characters!  The thing is that it was displayed in reverse font when I told it to use lower-case font.  I told it to use upper-case font (which was never mapped into VRAM) and it works... see attached screen shot.
 
I think VICE does not know about the secret "ignore bit 5 when font > 16 feature" that Tokra mentioned.
 
Anyway I attached D64 image that has BASIC demo program.  It just loads either NTSC or PAL ML program and prints some stupid text on the screen.... then it resets the hardware to standard after you "press any key".  You can press STOP at this point to remain in 32-pixel tall mode.  I don't know why but have fun...  Also there are REM statements near beginning of BASIC that describe change needed for either real C128 or VICE.  It is set to run in VICE so you need to change that for real C128.
 
More important the vertical centering is probably wrong... kind of hard to set it "right" because the position is based on font size... there is very low precision with 32-pixel tall font!
 
If you disassemble the ML program, you can see it uses the settings listed above.  You probably want to change the setting for register 7 which controls vertical position, but you don't have much choice!
« Last Edit: March 29, 2014, 07:37 PM by Hydrophilic »
I'm kupo for kupo nuts!

Offline tokra

  • VIC 20 user
  • ****
  • Posts: 150
  • Country: de
  • Reputation: 11
  • Gender: Male
    • View Profile
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #9 on: March 29, 2014, 09:52 PM »
Ok, here's my test-code:
Code: [Select]
10 fast:w=dec("cdcc"):bank15
20 sysw,7,25
30 sysw,31,9:rem 32 lines char height
40 sysw,8,4:rem 9*32=288
50 sysw,24,5:rem 312-9*32
60 sysw,6,6:rem 6 lines of 32 lines = 192 visible
70 sysw,8,7
80 sysw,255,23
90 sysw,95,28
91 sysw,0,18:sysw,0,19
92 fori=0to255:sysw,i,31:next
100 sysw,64,18:sysw,0,19
110 getkeya$
120 fori=0to65535:sysw,rnd(1)*256,31:next

As a handy VDC-reference I mostly use http://www.oxyron.de/html/registers_vdc.html

I set register 23 ($17) to 31, because with 32 (as with your vdc32.d64) I only get a 1 line high character display (lower 5 bits = 0, so character displayed height = 1). Obviously this is not desired. On the original setup it makes no difference display-wise whether it is set to 232 (factory setting: lower 5 bits = 8 ) or 231 (lower 5 bits = 7). Since the C128 PRG mentions
Quote
R23(4-0) can be equal to  or less  than  R9(4-0). 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.
it makes no sense for R23's factory default (232) to be larger then R9's factory default (231). I now believe Commodore engineers got confused with the +1/-1 stuff as well...

Anyhow, I tried your vdc32.d64 and with these minor adjustments it worked fine:
- your mentioned fix in line 20/25 for stock C128
- setting register 7 to value 8 or 9 (7 was too far down)
- setting register 23 to value 31

Now, the question remains what to do with those strange characters. These would probably make a lot more sense in interlace-mode, if you want double-height chars, maybe combined with double width. These might also come in handy if you increase the vertical resolution like I did in my VDC VGA-Mania mode. The text-mode you see in there is already 16 pixels high, since vertical resolution is doubled. If you wanted double-sized character in that mode the 32 pixel high ones give you that option.

I all comes down to the VDC being a very flexible chip that was probably designed to be able to provide a display signal on any device conceivable.

Offline Hydrophilic

  • 128D user
  • *******
  • Posts: 1429
  • Reputation: 233
  • Gender: Male
    • View Profile
    • H2Obsesson
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #10 on: March 29, 2014, 10:38 PM »
Cool thanks for testing on real HW.  I was just testing the setup logic and had not actually transfered to real C128 yet.  I did notice in VICE that register $17 would work with either value of 31 or 32.  So I guess the register really is only 5 bits wide since that value must be 31 on real hardware.
 
I did not even see that note about regsiter $17 in the case it is equal to total height.  I was just using the same logic as KERNAL which stores value of 8 in the default mode.  I guess it is okay to ignore that rule as long as you have < 32 pixel height for font?  Or in other words, the documentation is correct and the KERNAL is wrong (but it works for 8-pixel tall).
 
PAL has a bit of flexibility for vertical centering, but for NTSC the only sensible values are 7 or 8.  Anyway I fixed the software to use value of 31 for register $17 (char height -1), and value 8 for register 7 (vertical center)... thanks Tokra!
 
Edit
Changed reference of "char vertical display" from 17 (implied decimal) to $17 (hexidecimal).  It really is $17 (hex) or register 23 (decimal)... don't you just LOVE computers?
 
Edit 2
FYI, the BASIC program ends with some "strange" SYS commands that includes parameters of 0,0,0,4 and  0,0,0,0.  This just sets the CPU status register (P) which is almost never used... but I discovered the computer would lock-up without this!  To be precise, the KERNAL "IOINIT" $ff84 implicitly requires that interrupts be disabled... the 4 as last paremeter (first SYS) will disable interrupts, and for normal operation interrupts must be enabled... the last 0 parameter (final SYS).  You probably don't care, but thought I should document this for completeness.
« Last Edit: March 30, 2014, 12:34 AM by Hydrophilic »
I'm kupo for kupo nuts!

Offline tokra

  • VIC 20 user
  • ****
  • Posts: 150
  • Country: de
  • Reputation: 11
  • Gender: Male
    • View Profile
Re: Compute!'s 128 Programmer's Guide - ERRORS
« Reply #11 on: March 29, 2014, 11:29 PM »
Regarding register $17 (decimal 23) I suppose the KERNAL is wrong, but larger values than those in register 9 just do not matter.

I tried your fixed .d64 again on real hardware and even "forced" NTSC-mode. Works fine now (with line 25 replacement for line 20).

I played around a bit and for PAL you can easily fit 7 lines of 32 pixels. Then you need register 7 set to 9 though.