10 posts / 0 new
Last post
c128 VDC 64k addressing problem

Hi everybody

I decided to upgrade my c128 VDC to 64k. To test the RAM I wrote a Basic program that cycles writing 0 to 255 through all 64k. This was fine, but when I changed it to write the address high byte (stretch 0 to 255 across the 64k), I found location 0-16383 had taken on the same values as 16384-32767, and 32768-49151 were the same as 49152-65535. It sees the 16k Banks 0 & 1 as the same addresses, and Banks 2 & 3 as the same. I can write any two bytes, 16k apart, and the value will duplicate either direction.

At first this said to me that "A14" was stuck either on or off. I tested for continuity from each chip's pin of U23 & U25 back to the VDC, and for a short between any two pins of each IC. All tests passed. That's when I remembered RAM doesn't use 16 address lines. So now I'm stumped. Can the VDC malfunction so that A6 is stuck on or off with either CAS or RAS but not the other? Or can the problem still be somewhere else and not the VDC? Any ideas? I have a good multimeter and can borrow a scope but don't know what kind of signals to look for.

Re: c128 64k addressing problem

I can only think of 2 causes, a hardware error or a software error. If it's a hardware error, how did you attach the extra 64k? Was it through the use of an accessory board which you plugged in and which would give you the 64k? Or did you desolder the original 4164's and then install the 4464's? If it were through use of an accessory board, I've read that there may be a problem with its use.

If it's a software error, did you double-check your code? Perhaps you can try your program through another C128 with 64k or even through a C128DCR which already has the 64k VDC..

FCUG celebrating 33 years,
Robert Bernardo
Fresno Commodore User Group
http://www.dickestel.com/fcug.htm

I soldered in sockets and

I soldered in sockets and installed chips from Jameco. I wrote my own routines to test the RAM using SYS 52684, [high-byte] ,18 : SYS 52684, [low-byte] ,19 : SYS 52684, [value] ,31 to write locations, and SYS 52698,,31 : RREG A to read them. I wrote several different versions, and they all gave the same results, so I'm pretty sure they were right. I tried swapping chips but got the same results.
I borrowed a scope and have been reading the address lines using the CAS, RAS, and W lines to trigger the scope but I don't really know how to interpret what I'm seeing. I've only used one before to read audio-range waveforms. If my VDC is not defective, the only other thing I can think of is that I bought the wrong type RAM. They were the same Jameco part # (41574), as on Ray Carlsen's page, but he calls them 4464, which you did too. The chips I got are listed as "64k x 4" but say 41464. Don't know if that makes any difference.

Are you sure you didn't miss
Are you sure you didn't miss setting the register to tell the VDC its got 64k of memory? The flat 128s set this to 16k by default, so unless you change it to 64k the chip will simply think it has 16k and wrap at the boundaries when addressing. I forget the bit and register, but you need change this bit if you want to access more than 16k in a flat 128. I found it, its BIT 4 of REGISTER 28 ($1C) the flat 128 will by default set this bit to 0 (16k of VDC RAM) as its ROM's tell it to, since that's what its manufactured with, you need to set this BIT to a 1 telling the VDC it has 64k or ram to play with.. if you don't the VDC chip will simply loop at the 16k boundaries and you will see the behavior you are reporting.
Yeah, what badco said!
Yeah, what badco said! There was a long thread about different chips (16k or 64k) and how they behave in regards to VDC register 28 setting in a forum that is no longer available... It sounds like you need to set bit 4 to "on" (read register 28, do ORA #$10, write register 28). Here is simple test (conceptual)... write some value (like zero) to all 65536 bytes. Then write 1 byte of something different (like $21 for "!'). Finally scan through all 65536 bytes and look for any $21 (33)... if you get 4 addresses with that value, then VDC is still accessing the chips with 16K signals. If VDC (and chips) work correctly then (obviously) you should find only 1 address. To confirm, I have seen/used chips labeld 41464 for VDC (or was it 44164)... anyway I used that because I never could find any chip for sell that was simply called "4464". Good luck and keep us posted!

I'm kupo for Kupo nuts!

Thanks for the suggestions,

Thanks for the suggestions, but I think that's a misunderstanding of the spec sheet. Back in the day I read lots of upgrade articles and don't remember there ever being anything about having to change a register before running 64k software. Compute's Mapping The 128 states that bit is for an alternative board design that would have used two 64x1 chips instead of the normal 16x4 chips. The 64k x 1bit chips would still have equaled 16k total. Don't know why the VDC would need to know that anyway. The matrix shape is handled internally in a RAM chip.

My VDC does see the 16k blocks of 0 and 2 as seperate, and blocks 1 and 3 seperate. It just sees 0 & 1 as the same, and 2 & 3 the same. I think it's seeing a full 64k address space, but that the #6 bit (value of 64) is stuck on or off somewhere. As an interesting side note, I think the VDC always uses a 64k address space but with the stock RAM it only sees the same 16k, 4 times.

I bought some address decoder chips, LED's and driver chips, and borrowed a scope. I've been fooling around with everything but don't really know what I'm seeing on the scope or exactly what to try. I don't need 64k VDC RAM, I only did the upgrade while I was re-capping the board, so I think for now I'm just going to stick the 16k chips back in.

Targ,
Targ, I can tell you, the chip needs to be told it's got 64k by changing the but in question. If you do not the VDC will just loop adressing at the 16k banks. TRust me the chip engineers didn't put that control but into the chip because it wasn't needed. The 128d and the flat 128 have different Roms that have slight differences. One of those differences is that a flat 128 sets the ram size bit to the 16k setting when it initialized the VDC chip. If you attempt to address anything over 16k in a flat 128 without setting the bit to tell the chip it has 64k available the chip will just loop at the 16k boundaries back to 0. You may have something wired wrong but I can tell you in a flat 128 even if everything is wired right if you don't set the ram bit the chip will simply behave as it has 16k regardless of how much physical ram you have installed.
RAM and ROM

It seems like you, badco, have discovered an issue with ROM versus RAM. The original flat C128 had ROMs that always program the VDC to use 16K RAM... there is no test in the ROM...

I do not own newer "64K-Standard" versions (like C128DCR), but based on my analysis of ROMs available with VICE (and elsewhere on the web), the newer machines always program the VDC to use 64K RAM (there is not testing). In short, if you have "classic" ROMs, you will need a program to enable 64K VDC RAM...

Similarly, if you have "new" ROMs, you will need a program to enable 16K VDC RAM...

Umm, since you want 64K V-RAM, the first note above applies to you... in short, set bit 4 (hex $10) in register 28 (hex $1c)... and then 64K RAM should work fine (in any system)... hope that helps, but anyway, good luck and keep hacking!


I'm kupo for Kupo nuts!

Exactly!

This is what I was trying to inform the original author of. In a flat 128 they were manufactured with only 16k of VDC Ram.. so when the 128 initializes the VDC chip it tells the chip hey, buddy you only have 16k of ram to play with... so in a flat 128, if you try to write or read to addresses above 16k, the chip will just MOD the address with 16k and write and read from the appropriate address in the 16k. You can upgrade the physical ram all you want, but unless you tell the chip, you've got 64k now to play with, by setting the bit I mentioned, the chip will continue to behave as if it only has 16k because that is all it thinks it has.

In the D models they were manufactured with 64k so the when the VDC is initialized for use, the chip is told by the rom setup hey, chip you have 64k to play with, so addressing commands will access all 64k.

If you put 64k in a flat 128, and then try to address memory above the 16k boundary you will get the issue the original author is seeing, that being the chip just keeps writing and reading in the 1st 16k as you increase the memory addresses, it doesn't access anything above that boundary. You have to tell the chip explicitly it has 64k to play with by setting the bit in question.... Once you do this you can access all 64k in a flat 128, but by default you won't be able to reach it until you set that bit.

Below is a simple basic program to test ram size, look at line 20, that is the line setting the bit to tell the VDC it has 64k, see how it sets it explicitely before it checks? If you don't do this, in a flat 128 you will always get 16k back because the VDC is by default set to be in 16k addressing mode on those models.

Size of VDC-RAM:

Here's program to detect size of VDC-RAM:

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

Great program

Thanks for example code, badco... I have some assembly I could post, but the OP was using BASIC and I don't have anything written to quickly post...
 
Targ, you were also asking about how the chip can handle a 16-bit address. It uses a sneaky trick (common with all? dynamic RAM) which is to divide the address space into two parts.... (if you know assembly, it is very similar to low byte / high byte method). So during one phase (row address strobe) 8 bits are sent, and in the other phase (column address strobe) the another 6 or 8 bits are sent (total of 14 or 16 bits... depending if 16K or 64K).
 
In the simplest case, when the VDC is in '64K' mode, bits 0~7 of the address appear on pins 6~14 (except pin 9 which is power = +5V) during "phase 1" (row address strobe), and bits 8~15 appear on the same pins during "phase 2" (column address strobe).  16 bits total... 2^16 = 64K
 
But when the VDC is in '16K' mode, things are rather more complex... like before, bits 0~7 of the address appear on pins 6~14 (except pin 9) during "phase 1" (row address strobe).  But, during "phase 2" (column address strobe), bits 8~13 appear on pins 6~13 (except pins 9 and 10)... the important things to note are:

  • Neither pin 10 nor pin 14 are used in in "phase 2" of  16K mode
  • Only bits 0~13 (14 bits) are used, and 2^14 = 16K

 
How to explain?  So the VDC does this:
In phase 1 (row address strobe):

  • in both "16K and 64K modes", Pins 6~14 (except 9) are used for address bits 0~7

In phase 2 (column address strobe):

  • in "64K mode", Pins 6~14 (except 9) are used for address bits 8~15
  • in "16K mode", Pins 6~13 (except 9 and 10) are used for address bits 8~13

Sorry if that is confusing!  In short, generally pins 6~14 (except 9) are used... but in 16K mode, pins 10 and 14 ignored during phase 2 (column address strobe). 
 
I really can't think of a better way to explain... I hope that helps somebody... would love to hear a better explanation from anyone!
 
Disclaimer(s):

  1. the pin numbers above refer to the 4416/4464 RAM chip pin numbers (not VDC pin numbers)
  2. the info above is based on my limited experience... I'm sure Bil Herd could verify / correct what I have to say... after all, he designed the thing!

 


I'm kupo for Kupo nuts!

Log in or register to post comments