Denial

Sorry about my endless "newbie" questions ... Now my question is: what is the exact memory areas VIC-I can address in theory? I am a bit confused about VIC-I addressing (also something, that an address bus line is used in an inverted form in VIC-20), to be honest. Ie, is it possible VIC-I to access the last 24K of VIC-20 address space? Yes, the last 2*8K is basic and kernal, and the 8K below them is usually not used on a stock machine, but in theory, is it possible to program VIC-I registers in a way that it can access that region (any mean, including charset, video RAM ..., afaik colour RAM is fixed 4 bit SRAM, so it does not count). I'd love to see a "map" of *all* possible memory locations VIC-I can reach in VIC-20 even if it does not make any sense with a given hardware/memory expansion/etc configuration. I ask this, since I am curious which memory regions I am guaranteed not have shared bus access between CPU and VIC-I without the fear of bus conflicting if I do something "tricky" ... Thanks a lot in advance!

lgb wrote:Sorry about my endless "newbie" questions ... Now my question is: what is the exact memory areas VIC-I can address in theory? I am a bit confused about VIC-I addressing (also something, that an address bug line is used in an inverted form in VIC-20), to be honest. Ie, is it possible VIC-I to access the last 24K of VIC-20 address space? Yes, the last 2*8K is basic and kernal, and the 8K below them is usually not used on a stock machine, but in theory, is it possible to program VIC-I registers in a way that it can access that region (any mean, including charset, video RAM ..., afaik colour RAM is fixed 4 bit SRAM, so it does not count). I'd love to see a "map" of *all* possible memory locations VIC-I can reach in VIC-20 even if it does not make any sense with a given hardware/memory expansion/etc configuration. I ask this, since I am curious which memory regions I am guaranteed not have shared bus access between CPU and VIC-I without the fear of bus conflicting if I do something "tricky" ... Thanks a lot in advance!

Well, according to the datasheet you can get 16KByte continuous address space but in the Vic-20 it has been remapped so it gives you:

$0000-$1FFF which is were 5K of the internal RAM is, e.g. you can use $0000-$3FF and $1000-$1FFF

$8000-$9FFF which is were the character ROM is from $8000-$8FFF, VIC registers $9000-$900F, color map $9400-$95FF

Since any expansion memory is on the wrong side of the internal video buffer, the VIC chip can't read expansion memory. So adding any expansion memory is only going to be usable for the CPU (e.g. 6502).

Now Mike is probably going to tell you he has a hardware fix to get more video memory. So its possible, but it requires some soldering.

Kakemoms wrote:Now Mike is probably going to tell you [...]

... probably not.

lgb wrote:what is the exact memory areas VIC-I can address [...]?

I've put a more elaborate answer, also concerning the necessary arrangements of program and data, into a longer posting in another thread: http://sleepingelephant.com/ipw-web/bul ... php?t=7905.

That kind of questions should go into a FAQ, anyway.

Thanks for the information. Maybe I was not careful enough to read all messages of the corresponding threads on this topic ... but ... I'd like to also know, what is the hardware reason that VIC-I is not able to use expansion RAM if it's in the "right" place otherwise (ie, inside the addressable memory range by VIC-I). What happens if I try to set eg video RAM to a value would be in expansion RAM, dummy/random bytes are read instead of the actual memory content? Besides the "private business" of the 4 bits "wide" colour SRAM, does VIC-I use the "main" VIC-20 bus system to read (well according to the VIC-I pintout it does of course, but I mean other factors ie glue logic, whatever implemented in VIC-20 ... I could only find quite unusable schematics on the VIC-20 unfortunately ...)? I ask these probably silly questions, since I am aware of the bus sharing method of VIC-20, ie during PHI2 state of system clock, 6502 uses the bus, and the VIC-I during the PHI1. If I am right. Now I am wondering what happens, if I put something (ie SRAM) to the upper 8K "free memory window" (from $A000) which is used in PHI1 as well with my external stuff. Even if VIC-I wouldn't ever access that memory region (that's another part of my question, since I was also curious why VIC can't access the memory region which - by address - would be OK otherwise), the bus system is not "free" since used by VIC-I to address its accessible memory regions at least, so I would need to "isolate" my SRAM expansion not to have conflict between VIC-20 internal bus and my awful tries Thanks!

Simply put, the 6502 "owns" the address bus (CA0..CA13) at the cartridge port, at any time. External hardware is not supposed to enforce own logic levels on it. CR/W in conjunction with SΦ2, or VR/W, govern whether the data bus (CD0..CD7) is input or output.

Furthermore, the RAM select signals, /RAM1..3, the block select signals, /BLK1..3 and /BLK5, and the I/O select signals /I/O2..3 are output only. A cartridge is allowed to assert signals on the /Reset, /IRQ or /NMI lines with open collector outputs (there are pull-ups for those signals on the mainboard).

VR/W is recommended to use for the /WE pin of any attached RAM; CR/W is directly connected with the CPUs R/W pin and should only be used for peripheral chips which use SΦ2=1 to gate the validity of any other signals on the cartridge port.

There are no register values, which would put the base address of text screen or character generator into the address range of BLK5 - but anyhow, as I already wrote, nothing at the expansion port can be accessed by the VIC chip. If you program the VIC registers to read from $0400..$0FFF or any other area than $0000..$03FF, $1000..$1FFF (<- internal RAM) or $8000..$8FFF (<- character ROM), the video chip will only pick up bus noise.

lgb wrote:I mean other factors ie glue logic, whatever implemented in VIC-20 ... I could only find quite unusable schematics on the VIC-20 unfortunately ...)

What's wrong with those? ftp://ftp.zimmers.net/pub/cbm/vic20/schematics

Mike wrote:

lgb wrote:I mean other factors ie glue logic, whatever implemented in VIC-20 ... I could only find quite unusable schematics on the VIC-20 unfortunately ...)

What's wrong with those? ftp://ftp.zimmers.net/pub/cbm/vic20/schematics

An alternative is to download Eagle (free version) and the schematics from here. They are not 100% correct, but quite close. It makes it a little easier to see were the different lines are going.

Mike wrote:If you program the VIC registers to read from $0400..$0FFF or any other area than $0000..$03FF, $1000..$1FFF (<- internal RAM) or $8000..$8FFF (<- character ROM), the video chip will only pick up bus noise.

Forgive my failing and highly inaccurate memory but I do vaguely remember a solution to internally add a 3k expansion which is available to the video chip in the $0400-$0FFF area.

Interesting. I'm curious what would happen if I replace the lower 32K to a single SRAM chip, but *internally* (removing the original SRAM(s?) first). Then, RAM expansion is solved, cartridge port is not used, and *maybe* we can get some extra space at least (in the first 8K, if I see things well?) for VIC-I stuffs ... However I haven't got even the faint idea, how complex would it be, I mean the modification on the board itself ...

lgb wrote:Interesting. I'm curious what would happen if I replace the lower 32K to a single SRAM chip, but *internally* (removing the original SRAM(s?) first). Then, RAM expansion is solved, cartridge port is not used, and *maybe* we can get some extra space at least (in the first 8K, if I see things well?) for VIC-I stuffs ... However I haven't got even the faint idea, how complex would it be, I mean the modification on the board itself ...

You have to rewire to add a single 32KByte SRAM chip. Basically there are 8x3 lines on the 74LS245N buffers of which 8 are data and 14 are address. One is used for logic and one is unconnected. By wiring the unconnected wire to A14 you could in theory get all signals through to the SRAM chip (you would also need to add an adapter to get connected to A0-A13 + chip select/write lines. To get more video memory you would also need to add a wire from the 6560/1 (A13).

Lots of work, but probably doable if you have the time...

lgb wrote:I'm curious what would happen if I replace the lower 32K to a single SRAM chip [...]

... that could give some interesting effects with cartridges that map ROM into BLK1, BLK2 or BLK3.

Mike wrote:

lgb wrote:I'm curious what would happen if I replace the lower 32K to a single SRAM chip [...]

... that could give some interesting effects with cartridges that map ROM into BLK1, BLK2 or BLK3.

Well, yes, I can imagine that, however I haven't got a single cartridge for VIC20 Still there should be some configuration dip switches or such to enable RAM expansion in a given block for better compatibility.

lgb wrote:Well, yes, I can imagine that, however I haven't got a single cartridge for VIC20 Still there should be some configuration dip switches or such to enable RAM expansion in a given block for better compatibility.

You might take a look at 'The universal 6502 RAM/ROM Expansion' - to quote from the feature list:

x1541 wrote:VIC-20 computers:

* repair or diagnose computers with defective RAM and/or ROM chips.
* expand RAM to a full 32kB (configurable as 0kB, 3kB, 3kB+8kB and 3kB+24kB expansion)
* add four alternative versions of the VIC-20 system ROM
* add four internal cartridge ROM images at BLK5
* fully compatible with VIC-20CR only, the VIC-20 can not be closed with the expansion

However, the +3K at $0400..$0FFF sit on the "wrong" side of the address and data bus buffers in the VIC-20, and are still inaccessible for the VIC chip.

Put the question the other way round: what exactly did you have in mind with the (extra?) RAM for VIC-I?

Mike wrote:Put the question the other way round: what exactly did you have in mind with the (extra?) RAM for VIC-I?

Honestly? I don't know I just got to know VIC20 since some days (well, of course I knew even before that VIC20 exists, just I didn't know more about it than the fact about its existence, or something like that), I can say it's just "trying to know more" kind of questions I managed to write a primitive emulator for VIC20 within some hours (well, of course I wouldn't say it's better than one in VICE or such), since I have the odd habit, that the best way to learn about something is trying to emulate it The current version is better, more-or-less know what VIC-I knows (except multicolour currently) and "only" the timing is wrong (for example: it renders one scanline in "once" after 71 CPU cycles passed).

But anyway, back to the hardware: since some time, I had the plan to build my own SBC (single board computer) around a 65C02 or 65C816. My only problem is always with the video, that it's not so nice that I have some kind of serial port to be able to use, it's not the "true" feeling of something "complete" and standalone stuff built by myself. However, all of the existing solutions (ie some kind of video chip) uses its own private RAM (like the VDC in C128, but of course there more examples, even the example of MSX computers), or need a "complex" (well, for me ...) bus timing, extra cycles, whatever, like with VIC-II in C64 or TED in Commodore plus/4 and C16. But VIC20 and its VIC seems to be nice enough, quite simple bus sharing with PHI1 for VIC and PHI2 for the 6502 CPU, no extra cycles, whatsoever.

And then I thought, is it sane (well, 8 bit in general is not sane for most people in the world nowadays, anyway ...) to build a "new design" using VIC-I? What would happen, if I put a VIC-I, a 65C816 (well, so 6502 illegal opcodes won't work ...) on a board with some SRAM to build a stuff with "quite good" compatibility with VIC20, even by extending it (ie, more SRAM available for both of the CPU and the VIC-I). Also, the 65C816 can address 16Mbyte of RAM, extra RAM can be put "above" 64K (so bank number greater than 0) which is strictly "private" to the 65C816 with direct connecting. Ie, 65C816 would be able to use tons of memory. And if it uses only the higher banked RAM, it can be even clocked higher, until it needs to "touch" the bus which is shared with the VIC-I. In a PAL VIC20, I can even found the four times faster clock source, and about 4.4MHz should be enough (especially with my usual brain-dead strip-board designs, which are not so nice on higher clock frequencies too much ... The only problem, that 65C816 allows the stack and zero page only in bank 0 (though not at a fixed 256 byte page, like with 6502), and since it's on the "slow" bus, it would generally slows down the CPU a bit even if it's not in "VIC20 mode" but still needs stack/zero page of course. I would map the "VIC20 bus / address space" to a higher bank number, so for bank 0, still "fast" private RAM is used. It would not disturb the VIC20 mode too much, as 65C816 has output pin to signal "6502 emulation mode". This would override the bank remapping, allowing the "VIC20 bus" is accessed anyway. So everybody is happy Well, I think that, but who knows, it's only a plan now ... And it's possible that I am just dreaming, and it's useless (ie it won't speed up VIC20 mode too much, it's more about to create something which has some kind of "compatible" mode with an already existing computer for degree at least)

That's the other part of the question, that if a given RAM location cannot be accessed by VIC-I anyway, only by the CPU, than it could mean "fast" access even in VIC20 memory space ... Like the 8K "window" from $A000, which can be even used to map a part of the "extended" memory (from above 64K) even from VIC20 mode (or even, the ROMs would be not ROMs for real, but RAM mapped, and write disallowed, to "simulate" ROMs). However, I guess it's about the situation where I would need some kind of GAL/CPLD/etc, it would be too complex otherwise ...

But I am quite unsure now, that it worth to try to "rewrite" an existing VIC20 board (well, a lot, it seems), or it's indeed more simple to build an own stuff instead.

And no, I don't want to build a SuperCPU cartridge for VIC-20, it's kinda more complex stuff ...

Sorry for the long post, but since you've asked ...

I also have my share here in Denial with a few longer postings, so don't worry.

Some thoughts:

The main issue the developers of the VIC-20 originally faced, when putting 6502 and VIC-I into one machine was the 6502 could not tri-state its address bus. The VIC-I, on the other hand, plays nice.

The bus buffers separate these two sides, when SΦ2=0:

1. VIC, all internal RAM (including colour RAM), character ROM and register port lines of the VIAs, and
2. CPU, expansion port, KERNAL and BASIC ROM and chip select logic (including the register select lines of the VIAs).

So during its turn VIC can savely apply addresses whatever data (text screen or character data) it wants to fetch, without any interference by the CPU. Also, the colour RAM data bus is disconnected from the normal BD0..BD3 lines, and now solely connected to VD8..VD11, so VIC can fetch attribute data alongside the text screen data over its 12 bits wide data bus - text screen and colour RAM share the bottom 10 address bits, so they're always read out in parallel. SΦ2=0 also forces VR/W=1, so VIC always reads and - by any means - never will put destructive writes on the bus.

The addresses themselves go over the VA bus with its 14 address bits. For VIC-I, the RAM "sits" at $2000..$23FF and $3000..$3FFF (which is also the reason, the text screen and character base addresses in the register settings are so strangely permuted), and the character ROM is seen at $0000. There's a potential roll-over from $3FFF to $0000, from the end of RAM to the start of the character generator, which is used by many programs to display user defined graphics alongside ROM glyphs.


When the CPU takes over, VIC switches its address bus lines to input, and the address bus buffers are active in the direction CA -> VA. The data bus buffer is switched according to:

- *enable*, when source or target are on VIC's side of the data bus (i.e. internal RAM, character ROM, VIA register data pins),
- CD <- BD when CR/W = 1 (i.e. the CPU wants to read)
- CD -> BD when CR/W = 0 (i.e. the CPU wants to write)

There's no chip select logic for register reads of the VIC, it selects itself when it sees an address of $1000..$10FF on the VA bus (which corresponds to $9000..$90FF for the CPU) during SΦ2=1, and will either update its registers when VR/W=0 or output its registers, when VR/W=1.


You see, even with a simple computer like the VIC-20, there's already some engineering involved to get two bus masters working together as team. A simpler redesign might be doable with todays means - with dual-ported RAM. In that case, VIC could simply access its RAM as it wanted, and the CPU just can do the same. Also, the CPU can operate with another clock, and as VIC only reads, there can't be any write-collisions. Only register accesses need extra arbitration logic, i.e. the CPU must stretch its access cycle and allow VIC to snoop on the address bus for its own address range.

Kakemoms wrote:

lgb wrote:Interesting. I'm curious what would happen if I replace the lower 32K to a single SRAM chip, but *internally* (removing the original SRAM(s?) first). ...

You have to rewire to add a single 32KByte SRAM chip. Basically there are 8x3 lines on the 74LS245N buffers of which 8 are data and 14 are address. One is used for logic and one is unconnected. By wiring the unconnected wire to A14 you could in theory get all signals through to the SRAM chip (you would also need to add an adapter to get connected to A0-A13 + chip select/write lines. To get more video memory you would also need to add a wire from the 6560/1 (A13).

And

Mike wrote:... that could give some interesting effects with cartridges that map ROM into BLK1, BLK2 or BLK3.

I suppose it would be easier to replace the lower 8k to a single SRAM chip since the 1st 1k and the 4k RAM located at $1000-$1FFF are all in BLK 0.

AFAIK, that would be like a permanent built-in 3K RAM expansion that also happens to be visible by the video chip. No need to add a wire and no conflict with cartridges except perhaps the Super Expander's RAM portion (and you can no longer use the VIC-1210 but that's kinda obvious).