New hardware projects

[Mangelore]

Hi guys,

I've been spending some of my spare time working on a few small C64/128 hardware projects.

Feel free to check them out at
http://c64web.com
click on the Fotios Projects Link

Cheers
Fotios

[nikoniko]

Very cool projects, Fotios, especially the FB-512.

My dream 128 project, if I were more electronically inclined, would be finding a way to connect the VDC RAM to an addressable MMU configuration, eliminating the bottleneck of having to go through VDC registers for every read and write. However, I'm not even sure that such would be possible.

[Mangelore]

Very cool projects, Fotios, especially the FB-512.

My dream 128 project, if I were more electronically inclined, would be finding a way to connect the VDC RAM to an addressable MMU configuration, eliminating the bottleneck of having to go through VDC registers for every read and write. However, I'm not even sure that such would be possible.

Thanks! I have many more projects that I'd like to complete. At one point I was investigating the option of upgrading the VDC RAM to something like 128/256K. The problem though is that I'd need to introduce more address lines to the VDC which would be a real hack job. You'd still need to use the VDC registers for read/writes. It would also end up being two projects, one for the C128 and one for the 128DCR as their VDC's are different.

Another crazy idea was to create VDC cartridge for a C64. But the last thing I want is 64 users stripping VDC chips out of 128's to use with a 64.

As I lack the software skills required to fully test the above projects so I decided to focus on easier stuff for the time being.

You're idea for VDC RAM that's addressable via the MMU is an interesting one. Maybe if I create a board similar to the 64K VDC upgrade for the 128

http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=160149180979

but also tap into the VIC chip to grab the address lines so my board would also have a socket for the VIC chip. Don't quote me on anything at this point as I haven't done much with the VIC chip. If possible, which memory address would you like to tap into for the VDC?

[nikoniko]

At one point I was investigating the option of upgrading the VDC RAM to something like 128/256K.

That would be pretty handy for a GUI, having plenty of memory to store hidden or overlapped areas. It would also be very nice for large scrolling screens or text buffers. Plus, what one doesn't need for video could be used as a RAM disk!

You're idea for VDC RAM that's addressable via the MMU is an interesting one. If possible, which memory address would you like to tap into for the VDC?

I'd be happy enough to have it available anywhere. I imagine it would be difficult to expose the full 64K of an upgraded VDC, but even 16K would be extremely useful. When dealing with 64K, the VDC's fast block copy operations should be sufficient for shuffling memory around from an exposed 16K window to other parts of memory (eg. you could use the system addressable RAM as an offscreen drawing area from which to copy to the main screen).

I don't know if this document which discusses expanding the internal memory of the C128 would have any helpful clues, but here it is just in case: http://www.ktverkko.fi/~msmakela/8bit/memory/memory-c128.pdf

[Mangelore]

You're idea for VDC RAM that's addressable via the MMU is an interesting one. If possible, which memory address would you like to tap into for the VDC?

I'd be happy enough to have it available anywhere. I imagine it would be difficult to expose the full 64K of an upgraded VDC, but even 16K would be extremely useful. When dealing with 64K, the VDC's fast block copy operations should be sufficient for shuffling memory around from an exposed 16K window to other parts of memory (eg. you could use the system addressable RAM as an offscreen drawing area from which to copy to the main screen).

Hmmm... if you had to pick a 16K range of RAM to use as VDC VRAM, which memory range would be the least likely to cause compatibility issues with existing software applications?

Does anyone use the 40 column VIC (8KB isn't it?) screen RAM when in 80 column mode?

I can see this discussion needing a thread of it's own

[nikoniko]

Hmmm... if you had to pick a 16K range of RAM to use as VDC VRAM, which memory range would be the least likely to cause compatibility issues with existing software applications?

Does anyone use the 40 column VIC (8KB isn't it?) screen RAM when in 80 column mode?

I can see this discussion needing a thread of it's own

The 128's MMU can switch in an additional two 64K banks of RAM (RAM 2 and RAM 3) at will, or expose portions thereof in the current configuration, so there wouldn't need to be any compatibility issues. Any software not designed to use the new feature would never even see the RAM. I think the main consideration would be not to overlap the IO area where the VDC's control registers reside, as then you'd have to keep switching IO in and out to do things like block copy, etc. Probably the ideal would be to have VDC memory set up as RAM 2 and swapping in at $8000-$BFFF. I suppose one could even do 64K, but programmers would have to take into account that a few locations at the very beginning of RAM and very end of RAM wouldn't be accessible, so it would actually be 64K minus a little bit.

Alternately, maybe one could take over the mapping for the internal function ROM, though people who do have a ROM in there might find that annoying unless it was switchable somehow.

In case it's helpful in understanding the 128's memory management, here's an excerpt from Mapping the 128 regarding the MMU configuration register at $FF00: http://furthervoyages.com/mmu.pdf

[airship]

EXACTLY what I wish they'd designed into the original C128: the 64K of VDC RAM would also be visible as a standard BANK to the MMU.

[nikoniko]

I guess they didn't feel that the performance of the 80 column display mattered so much since it wasn't really intended for much more than text display. Certainly the VDC itself is very speedy and capable, but it's hard to make the most of that given the IO situation. Had there been direct RAM access I'm positive we would have seen much more done with it.

[Mangelore]

The VDC is an interesting chip as it has it's own seperate data and address buses to it's own VDC RAM. There's no hard wired path to the VDC RAM other than the one via the VDC chip. This would be one tricky hack to pull off and I'm not sure I have the expertise to do it.

We would somehow need to interface the VDC RAM chips to the main C128 address/data buses  and also introduce some form of memory management. However, while the C128 system data bus is present at the VDC, the C128 system address bus isn't.

I suppose would could try tapping into the C128 system address bus from the U36 function ROM socket.

[nikoniko]

Maybe we'll be lucky and Bil will drop by and see this discussion. Perhaps he'd have some ideas how to go about it, if it's even possible.

[Blacklord]

Maybe we'll be lucky and Bil will drop by and see this discussion. Perhaps he'd have some ideas how to go about it, if it's even possible.

He browses every couple of days - PM him to alert him maybe ?

cheers,

Lance

[Guest]

I suspect the VDC refreshes its DRAM differently than the main bus and could be the very reason that its memory is completely isolated.  The VDC was designed for systems with varying CPU speeds and video circuitry is particular about timings.

[8502]

I suspect the VDC refreshes its DRAM differently than the main bus and could be the very reason that its memory is completely isolated.  The VDC was designed for systems with varying CPU speeds and video circuitry is particular about timings.

Indeed.  You would have to cross VIC (the master clock generator in the 128) and VDC (which has an independent clock) clock domains to get this to work.  IIRC, this is also the reason you have to wait for the VDC to be 'ready' between accesses.

cheers,
paul

[nikoniko]

Ah well... so much for my ignorant dreams.

[airship]

So it would take a whole CARD to manage. So what? It would still be cool.