6560 Access to $9800-$9fff

[DrVeryEvil]

Has anyone tried adding a 2k memory that the VIC could access at $9800-$9fff? It would seem this could be done in a similar fashion as the color ram, adding another area to place the screen matrix. Just a thought.

[buzbard]

Have you looked at this thread? Ultimem

[Mike]

Providing VIC with VRAM in the range $0400 to $0FFF might be a more practical solution, than doing so for $9800 to $9FFF. Even though the latter could be done as well, it would require to block this address range entirely for external cartridges, rendering Mega-Cart, FE3, and also UltiMem largely non-functional.

The fact that VIC is not capable of accessing any external memory still seems to go unnoticed by quite some people.

Furthermore, the colour RAM is not accessed by VIC in the same way as by the CPU: an analog switch separates that RAM from the data bus during the VIC 'half' of each clock cycle, and instead connects it to another 4 bits wide data input, so VIC can fetch text screen and colour data in parallel over a 12 bit bus. But this also means, that VIC cannot access the colour RAM over the 'normal' data bus: neither as text screen, nor as character data (and anyway, it is only 4 bits wide).

[DrVeryEvil]

Providing VIC with VRAM in the range $0400 to $0FFF might be a more practical solution, than doing so for $9800 to $9FFF.

I have already done that in my VIC 20 65816 project, http://forum.6502.org/viewtopic.php?f=4&t=3521, and moved the start of basic to $600 and the screen matrix to $400. This works great, although compatibility has gone out the window in this configuration, which doesn't bother me. Its all about pushing this little computer to do things it never could, and in my book, change its memory map to what it should have been.

The fact that VIC is not capable of accessing any external memory still seems to go unnoticed by quite some people.

Furthermore, the colour RAM is not accessed by VIC in the same way as by the CPU: an analog switch separates that RAM from the data bus during the VIC 'half' of each clock cycle, and instead connects it to another 4 bits wide data input, so VIC can fetch text screen and colour data in parallel over a 12 bit bus. But this also means, that VIC cannot access the colour RAM over the 'normal' data bus: neither as text screen, nor as character data (and anyway, it is only 4 bits wide).

Here's my idea on using IO2 and IO3. I have a small board VIC 20. I have already removed the two, 2K SRAM chips and replace them with an 8K SRAM to make VRAM from $0000 to $1FFF. This is placed on a board along with the character ROM and plugs into the character ROM socket. Now, what if I put a 2K SRAM back in one of those spots, with the /CS and /OE left out and disconnected. I could AND IO2 & IO3 together, then OR PHI1 with the output from the AND, and put them on /CS and /OE, sort of like the colour memory is qualified. So this wouldn't actually be hooked up to bits 8 - 11 of the VIC data bus. It would be available on the CPU data bus also, (bits 0-7). Despite the fact that Mega-Cart and FE3 would not being able to use this area, it could allow for the screen matrix to be placed at $9800, opening up more contiguous memory for basic programs, as well as other possibilities.

[Mike]

Except it won't work the way you described. I/O2 and I/O3 are generated in UC6 from the CPU address bus. VIC puts addresses on its VA bus - where also the character ROM is connected to -, but these addresses never reach the CA bus. You'd have to "replicate" the functionality of UC6 on the VA bus to make room for RAM in I/O2 and I/O3, and that RAM then is selected in the translated address range $1800 to $1FFF. The new address decoder needs its select signal qualified with the same timing that UC4 takes to select /RAM0../RAM7. Finally, you'd need to detach the "old" I/Ox signals from UC6, instead tying those to a permanent H-level (which you hopefully also did with the old /RAM1../RAM3 signals!) over pull-up resistors so:

• UD9 in conjunction with UF8 actually doesn't block CPU access for those address ranges, and
• cartridges get a defined "not selected" signal instead of possibly undefined levels from the *inputs* of UD9! *)

BTW, instead of a permanent change in the KERNAL to move the screen to $0400 and the start of BASIC to $0600, I just utilize a small program (max.prg, download) which reboots the VIC-20 to exactly that memory configuration. That being said, is the gain of another whopping 512 bytes of BASIC memory really worth losing the compatibility to those aforementioned cartridges?


*) On open TTL input is considered H-level (albeit only barely) by the chip itself, but another chip sees a voltage level of around 2.4 V from that input pin, which gives an undefined logic level in case you have another input of a CMOS chip on the other side!

[DrVeryEvil]

I/O2 and I/O3 are generated in UC6 from the CPU address bus. VIC puts addresses on its VA bus - where also the character ROM is connected to -, but these addresses never reach the CA bus.

You are correct, but you are only telling half the story. There are three 74LS 245s separating the VA and VD buses from the 6502. If you recall, the 6560 can access 16K of memory. The first 8K is from $0000-$1fff. The second 8K is done by slight of hand, through UC5 and UE8. This is how the character ROM can appear at $8000. I take advantage of this to place 4K of memory in the same space as the character ROM, in much the same way as the C64 does...and it works.

Finally, you'd need to detach the "old" I/Ox signals from UC6, instead tying those to a permanent H-level (which you hopefully also did with the old /RAM1../RAM3 signals!) over pull-up resistors so:

With my internal 3K, I pulled a simple trick by taking the select lines, pins 1,2, & 3, and separating them from the VA bus and tying them to ground. RAM0, then controls the 8K ram chip that replaces the 5K that was put there originally. Since $0000-$03ff is available to the VIC already, the whole 8K is also made available. Another slight of hand, you might say.

Since you can access the color memory with the 6502, which goes through UC6 as IO0, that means I can add memory to IO2 and IO3 by connecting the VA & VD0-VD7bus to my ram, qualify it in the same manner as UE8, and I have another 2K available to the VIC.

Sure, this makes the memory map and capabilities different, but my whole idea is to improve the VIC 20. I'm not a purist, which a whole other challenge.

[Mike]

You are correct, but you are only telling half the story. There are three 74LS 245s separating the VA and VD buses from the 6502.

If you actually take the time to read some older posts of me, you'll surely find enough references to those three bus buffers. I just thought repeating myself wasn't necessary here.

Sure, this makes the memory map and capabilities different, but my whole idea is to improve the VIC 20. I'm not a purist, which a whole other challenge.

I'm surely fine with removing some limitations of the VIC-20 motherboard, which just were built in by accident.

However, I do not consider those improvements as an end in themselves, they need to serve some purpose. Just putting some extra RAM at some place - just because it can be done - doesn't cut it for me: In case of my VFLI mod,

• I put that RAM in place specifically for the purpose VIC can also access it, for an expanded bitmap,
• Furthermore I put a 16Kx4 SRAM in place of the original 1Kx4 SRAM of the colour RAM, for 1 pixel high attributes over the whole screen width,
• I wrote myself the necessary display routine to put this bitmap - 208x256 pixels, 3 global colours on each raster, 8x1 colour attributes - on screen,
• I also wrote a converter, which runs on a PC, takes an arbitrary image and produces a conformant VFLI bitmap for display on the VIC-20.

Finally, I put everything together in the thread about the VFLI mod I already linked to here, so everyone with the necessary experience should be able to reproduce the mod. If that thread hadn't been met with only such a lukewarm response, I surely would have followed up with other applications, like a BASIC extension, etc. - but for now I'm working on other projects.


I should add, that my modified VIC-20 still happily runs practically everything of software and hardware I tried out in the last five years. Only the fact, that 4 bits of the user port are used to select the upper 4 address bits of the expanded colour RAM precludes the use of the KERNAL RS232 routines, but I can live with that. After all, it *is* a user port.

[DrVeryEvil]

However, I do not consider those improvements as an end in themselves, they need to serve some purpose. Just putting some extra RAM at some place - just because it can be done - doesn't cut it for me.

I must agree that there must be a method to the madness. Whether I will impliment it, is another story. I'm more curious if it will work and I will be able to move the screen matrix totally out of the way of basic and into this new area, as shown on page 132 of "Computes' Mapping the VIC 20".

We are really on the same page. I just wish I could code better. The stuff that can be done with ML is so interesting to me, I just need to learn how to do the stuff that involves more difficult math. I have done some interrupt programming, in order to communicate with my X-10 controller without their funcky interface. I have done a crude, but working split screen with 176 x 160 bitmap with four lines of text below it, and implemented a simple turtle graphics interpreter. I am working on better understanding the finer details of cycle counting and the raster. Graphics manipulations have always been a little over my head, as far as translations and projections, but am trying to understand that. I have implemented ram underneath both the kernal and basic ROMs, and have a working version of "Fast Assembler" from Computes' Gazzette.

I just need to round out my software abilities to make better use of the hardware mods. You have truely done some amazing things with your VFLI, and I do plan on implementing your 16K x 4 colour ram mod. I may even put in a switchable EEPROM with four different kernals in it so I can have my modified kernal along with the stock kernal, both with and without Jiffy-DOS. I look up to you guys on this forum and the 6502.org forum and want to learn more.

Thank you for all your input.