Confused about 16K/64K testing code in the comp.sys.cbm FAQ...

[nikoniko]

Inasmuch as I understood the VDC, if you had 16K of VDC RAM and tried to access an address of $4000 or above (beyond the end of RAM), the operation would wrap around. So if you wrote $FF to $4000, it would show up at $0000. Likewise, if you tried to read the byte at $8001, you'd get back the byte stored at $0001.

With 64K of RAM, naturally, this wrapping wouldn't occur.

Because of this behavior, one way to test the amount of RAM installed would be to write something at $0000, write something different at $4000, then read $0000 and see if it changed. If it changed, you have 16K, otherwise you have 64K. Works in VICE, which probably isn't saying much.

If that's correct, then I can't make head or tail of this code from the comp.sys.cbm FAQ:

Code Select Expand

 1 rem fred's nifty program to determine size of 8563 dram
  5 w=dec("cdcc"):r=dec("cdda")
  10 bank15: ad=dec("d600"): da=ad+1 :rem setup ml
  20 pokead,28: s=peek(da): pokeda,63 :rem select 64k
  30 i=16896: sysw,i/256,18:sysw,iand255,19:sysw,85,31 :rem write $55
  40 i=16896: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc1 :rem read here
  50 i=17152: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc2 :rem and here
  60 i=16896: sysw,i/256,18:sysw,iand255,19:sysw,170,31 :rem write $aa
  70 i=16896: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc3 :rem read here
  80 i=17152: sysw,i/256,18:sysw,iand255,19:sysr,,31:rregc4 :rem and here
  90 pokead,28: pokeda,s:sysdec("ff62") :rem restore 16/64k
  95 print chr$(14)chr$(147)
  100 if c1=c2 and c3=c4 then print "16K": else print"64K"  :rem did it echo?
  110 end

[Golan Klinger]

I've always used "POKE DEC("D600"),28:POKE DEC("D601"),63:SYS DEC("FF62"):SCNCLR" because it was short, sweet and easy to remember.

[nikoniko]

Mostly I'm just trying to understand how "fred's nifty program" would ever succeed in what it's supposed to do. But we should add your short and sweet tidbit to the Tips section if it's not there already.

[hydrophilic]

I can't explain it, but it has to do with the way multi-plexing works.  The 4416 multiplex differently than (what 4464s?).  That's why there is a bit in the VDC control the RAM/multiplexing.   So in 16K mode the VDC sends 7x7 = 14 bit multiplexed address but 8x8 = 16 bit address in 64K mode.  There's a 4-bit gap at after the first 7 bits or you could say bits 8~11 are indeterminate.  $4300-$4200 = $100 difference at bit 8 which isn't seen by the 4416.

That's my theory.  See told you I couldn't explain it!

[nikoniko]

Ah... that sounds reasonable. Or at least sounds like it would be if I were a bit smarter, more awake, or both.

Just found something in the PRG I hadn't paid any attention to before in the entry for R28:

Code Select Expand

4416: Row/Col = A7/A15, A6/A13, A5/A12, A4/A11, A3/A10, A2/A9, A1/A8, A0/A8
4164: Row/Col = A7/A15, A6/A4, A5/A13, A4/A12, A3/A11, A2/A10, A1/A9, A0/A8
I'm not really clear on how to interpret that, but I'll assume it confirms what you wrote.

Unfortunately VICE employs the same incorrect understanding of memory as I had described:

Code Select Expand

static int set_64kb_expansion(int val, void *param)
{
    vdc_resources.vdc_64kb_expansion = val;

    vdc.vdc_address_mask = vdc_resources.vdc_64kb_expansion
                           ? 0xffff : 0x3fff;
    return 0;
}

[hydrophilic]

Yes the wiring of the pins is different but that pin listing is very questionable.  For example, the 4164 does not have an A14 !!  And the 4416 has an A15...

I've never seen a 64K VDC unit, but people say they have two RAM chips just like the 16K units.  If so, they can't be 4164s because you need 8 of them.  That was the reason for my 4464? remark.

Opinions are free.  Answers are free.  Correct answers are $10000000000.  (Space travel is expensive).

Looking at your diagram there, all the high order bits are shifted up (except A8).  So if thats correct, when VDC in 64K mode sends an address, the 4416 would see the high byte (page) as divided by two.  So storing to $4200 would goto $2100.  Storing to $4300 would also goto $2100 ?  Or maybe $2000 (depending on which A8 it likes)?

Or in 16K mode the 4164/4464 would see the page doubled, and plus 1 if its an odd page.  So storing  to $2200 would goto $4400 while storing to $2100 would go to $4300 ?

Now I'm confused :/

Well that diagram screws up half my theory since I thought the high bits A7/A15 would be lost but at least one is at the other (low) end, (that doubled A8).

[nikoniko]

I know it shouldn't be used lightly, but maybe the Bil Signal will bring the help we need.

[airship]

I usually don't lower myself to using chat room acryonyms, but this certainly deserves at least two, and maybe even a big smiley:

LOL!!!! ROTFL!!!!!!!

[Blacklord]

I know it shouldn't be used lightly, but maybe the Bil Signal will bring the help we need.

Oh cute! :hurra:

[nikoniko]

I should've found a picture of Bil in profile to replace Batman, but who knows.... maybe Bil dons a cape sometimes too.

[hydrophilic]

Too funny :lol: :lol:

I just checked the schematics and ran some tests.  The 4416 does have 8 address lines so my theory is completely wrong (I must have been thinking about ROMs and their reduced number of address lines).

Apparantly the table from the PRG is correct except for the missing A14 in 64K mode.  I guess the VDC sends out A15 even in 16K mode though the 16K RAM will ignore it.

Enough theory.  I did some tests too.

In 16K mode (with 16K RAM), the C128 operates just like the VICE code.  In other words, the high 2 bits are simply chopped off.  Write to $5000 or $9000 and you can read it from $1000.

In 64K mode (with 16K RAM), the C128 divides the hi byte of the address by 2 (and then the original highest bit is ignored).  So storing to $1000 or $1100 goes to the same memory address.  This data can be read from $1000 or $1100 (also $9000 or $9100).  If you switch back to 16K mode, you will find the data at $800.

In other words, in 16K mode data can be found at 4 places:
a
a+$4000
a+$8000
a+$c000

While in 64K mode data can also be found at 4 places:
(a / 256 and 254)*256 + a and 255
((a / 256 and 254)+1)*256 + a and 255
$8000+(a / 256 and 254)*256 + a and 255
$8000+((a / 256 and 254)+1)*256 + a and 255

I don't have a 64K unit so no experments possible the other way around.

Hope this helps.

[nikoniko]

That helps quite a bit. Thank you for your investigation! That would explain, too, line 20 above which puts the VDC into 64K mode.

Say, if you have a chance, would you run another experiment? It won't take much time.

Would you try changing the start address of screen memory to begin right before the end of 16K RAM? I recommend 80 bytes, or one text line, before the end... I think that would be $3FB0. I believe that after the VDC reaches the 16K barrier while drawing the screen, it should wrap around and grab data from the start of RAM. If so, then you should see your text screen pushed down one line. Doesn't work in VICE, but I think it should work on a real machine. If it does, I'll post an article about a very cool and practical use for that characteristic.

Code Select Expand

10 bank15:w=dec("cdcc")
20 sys w,dec("3f"),12:sys w,dec("b0"),13 :rem Change start of screen memory to $3FB0
30 getkey a$
40 sys w,0,12:sys w,0,13 :rem Restore start of screen memory to its default of $0000

[hydrophilic]

Your code works.  I can think of sever handy uses for this feature... looking forward to whatever it is you're up to.

Strange that VICE doesn't work.  I'm guessing the actual display code 'forgot' to use the mask that was correctly setup!

[Guest]

If you enjoy playing around with VDC chip in the C128, a must read on the subject is chapter 5 of Abacus Software's book called '128 Internals'.

The article that got my attention was, 'More than 25 lines on the screen'. I have written several routines that add extra lines to the 80-col screen. I use it in all the programs I write for myself. It's used to display all the command definitions for that particular program.

I have two routines that I wrote for our local computer club. One of the programs I sent to Fotios to run on his VGA setup. I wanted to know if it would show up on the RGBI-VGA screen, and it worked just fine. Fotios sent me a screen shot of the display.

Anyway the chapter will really get your mind reeling with ideas.:ironisk:

Dan...

[nikoniko]

Your code works.  I can think of sever handy uses for this feature... looking forward to whatever it is you're up to.

Thanks! This article will be a little nicer than my others since I have demonstration code to go with it. I worked on it a couple weeks ago, then was dismayed when it didn't work in VICE. Until you did your test, I wasn't sure if that was VICE's fault or an annoying limitation of the VDC, so I'm delighted to find out it was only an error in VICE.

Feel free to share your ideas as well, either here or when I post my piece later. Basically I wrote a routine to do super easy infinite vertical scrolling of a bitmap display.

By the way, it would be great if someone with 64K of VDC RAM could confirm whether the same wrap around occurs at the end of 64K space. Just change the "3f" to "ff" in my test code. Actually, does one also have to set 64K mode even when 64K is available? If so, you may need to add the stuff from line 20 of "fred's nifty program" to the end of line 10 in my code.

Strange that VICE doesn't work.  I'm guessing the actual display code 'forgot' to use the mask that was correctly setup!

Indeed, that must be what it is. Should be an easy fix, and I'll submit a patch to the VICE team afterward.

[airship]

Dan, Cool! I've got a copy of C128 Internals coming in the mail right now!

nikoniko, super-cool! Can your routine work with TEXT, too? I'd like to be able to scroll up and down in a file that's completely stored in VDC RAM. Think how cool that would be for help files! Use one regular screen for the program, hit a key and instantly be able to scroll through a text file, then pop back to the program. No print routines, no loading from disk. Resident help.

[nikoniko]

It can work with text, with some modifications that I'm working on. The only issue is the character definitions. Not that big a deal though since when you're about to run into them, you can just stuff them to another part of memory with some block copies. It will introduce a slight hiccup in scrolling, but I don't think that will be too significant.

Also, one needs to use interleaved screen and attribute memory to pull it off... so it's a good thing I came up with that.

Dan, thanks for the Internals recommendation. Sounds like a good one to pick up.