Denial

TLovskog wrote:The reason to go for the ROM was that I, at the time, thought it would be easier to add wires / break traces than to de-solder ICs.

Breaking traces on the mainboard is a semi-permanent change to the mainboard, which can only be reverted by patch wires. Soldering wires to pins of soldered-in chips is, IMO, a botch. If I don't care (or don't need to care) about the original chips, desoldering is as easy as clipping off all pins, extracting them one-by-one, and placing a socket as it is done when exchanging a bad chip. Here, the chips involved are either standard TTL logic ones, or SRAMs still readily available. With the sockets put in, it is also easily possible to revert the mod. The pull-ups for /RAM1..3 can remain in place. At that time, I wanted to keep the original chips, though. It wasn't quite easy to extract them, but here they are:

Another approach then to get nearly the same signals is to have a PCB that plugs into socketed UC4, UD4, UE4, as well as UC5 and UE1. The additional two "ports" would give me access to the color ram

For the complete VFLI mod, my approach handles UE1 separately from the expansion of internal RAM from 5K to 8K. As all signals are available at the socket of UE1, and the 16Kx4 SRAM shares the bottom pins, I didn't need a PCB here either. I thought about adding a register to provide the extra 4 address bits, but then the easiest solution was using the user port for this. After all, it is a *user* port.

and the whole address decoding logic. Making it possible to add RAM at BLK1-3 and 5. Well actually also 6 and 7.

Being able to replace BASIC and KERNAL ROM by soft-loaded versions might have been nice to have, but were neither the aim nor necessary to display VFLI images. And BLK1..3 and BLK5 can be provided by any external memory expansion, so I didn't include that either.

The only missing signals is IRQ which I had in mind for raster interrupt.

How would that make it easier to start the display routine for VFLI images with single cycle accuracy, compared to the method using VIA timers?

How would that make it easier to start the display routine for VFLI images with single cycle accuracy, compared to the method using VIA timers?

Well it is more a effect of another feature. I have thought of a mode where the electronics supplies a "faked" character screen where the character code is calculated from the screen address. These are then mapped as usual to a address of character graphics in 8x8 matrix. The calculations can handle 4 x 256 8x8 characters. The character graphics pointer is also moved as the "faked" characters spills over from 255 (actually the base address stays, but the ram is remapped). Same operations with the color ram.

As a effect of this it is also easy to generate an interrupt at a certain row. Since I have full control over BLK7, I can generate vectorized interrupts. So it is easy to set up an list of raster lines and addresses to functions for that row ...

I once had something similar in mind, using a controller to "inject" new register values (especially those four necessary for $9005, $900E, $900F and the colour RAM bank), as (Atari/Amiga-like) display list. That would allow to put a VFLI image on display with essentially zero overhead: For each displayed raster, one cycle to assert RDY, 3 wait cycles to allow the 6502 to finish up to 3 writes, and then the four register writes, while the 6502 idles. Timed so the register writes happen during HSync.

Could be implemented with two counters, one for the 71 or 65 cycles per line, the other one for the 312, 261 or 525 rasters per frame. At one time, it would be necessary to reset and start that counter pair, but that could be done with one of the established methods doing stable rasters.

Regarding the interrupt facility you brought into play: even when asserted at a given fixed horizontal position, the 6502 needs up to 7 cycles (8 for some illegals) to finish the current instruction, +3 if the IRQ happens during a taken branch (one that doesn't straddle the page boundary), so it's not stable. And you still have to do the housekeeping for all the CPU registers used in the vectored routines. For niceness, we assume the foreground process didn't do a SEI.

Is the 'faked' text screen data (using your approach of an address generator) going to provide any advantage beyond some saved memory?

I once had something similar in mind, using a controller to "inject" new register values (especially those four necessary for $9005, $900E, $900F and the colour RAM bank), as (Atari/Amiga-like) display list. That would allow to put a VFLI image on display with essentially zero overhead: For each displayed raster, one cycle to assert RDY, 3 wait cycles to allow the 6502 to finish up to 3 writes, and then the four register writes, while the 6502 idles. Timed so the register writes happen during HSync.

Interesting!

I suppose we then need to get control over the address buffers to keep the 6502 address high-z stated when we (during the 6502 part of the clock) adds $9004 etc and data to simulate register updates. Today it is directly tied to clock out from the 6560/61. The data buss is already under control through the 13 input NAND gate.

We also need to separate RDY and SO pin on the CPU since they share the same pull-up.

Devilishly intriguing.

Can VFLI mode be done with RAM expansion board via the cartridge port, that is, without doing the hw modification you outlined?

inspired by this thread i hacked a bit.... ... now before i commit it, could you (mike) please confirm what i did:
- the VIC can "see" all RAM in $0000-$1fff range
- the colorram was extended from 1k to 16k
- colorram address bits 10-13 come from VIA1 PB bits 0-3 (userport pins C-F)
- every instance of the VIC or CPU accessing colorram uses the new address scheme
(and of course you need to enable ram in block 0 and block 1)

if you spot obvious mistakes please shout (does this count as the third VIC with this mod? =P)

edit: cleaned it up a bit and committed anyway (r30797) - please test
edit^2: use -vflimod to enable

groepaz wrote:[...] could you please confirm what i did:
- the VIC can "see" all RAM in $0000-$1fff range
- the colorram was extended from 1k to 16k
- colorram address bits 10-13 come from VIA1 PB bits 0-3 (userport pins C-F)

Check. Check. Check - when the DDR is set to input, those four bits should default to high, and thus select bank 15.

- every instance of the VIC or CPU accessing colorram uses the new address scheme
(and of course you need to enable ram in block 0 and block 1)

Check. And Check - however IMO -vflimod should force RAM for block 0 anyway. No point in having the VFLI mod without RAM in $0400..$0FFF. I didn't include an enable switch - if a program requires the original RAM setup on the real h/w, I run a small program to set the limits of BASIC for 3583 bytes free.

Block 1 isn't strictly necessary. It's just required for anything that needs RAM there, like of course those slide shows.

if you spot obvious mistakes please shout

No obvious mistakes, but possibly one other thing to be wary about: the VFLI mod needs to explicitly disable *external* +3K expansions of any kind - see reasons here. If those +3K come with extra functions, like banking or write-protect (on FE3), that doesn't work anymore on real h/w. Gives quite some cross-dependencies with all those cartridge simulations ...

In practice, it's for the moment only the write protect of the FE3 wedge which isn't anymore present. Also, on Mega-Cart, "unexpanded" doesn't mean anymore 3583 bytes free, but rather now 6655 bytes free, and I need to run the aforementioned utility to reduce it to 3583 with BASIC starting at $1001.

Just so one doesn't fall into a trap when he writes a program that requires both VFLI mod && (Mega-Cart || FE3 || UltiMem), and doesn't take into account, that the +3K don't anymore come from the cartridge, and thus don't anymore have the cartridge's extra functions.

...

Thanks!

is there a simple way to test for this problem?

Parts ordered to do this mod, some from Germany and some from China, prepare for some possible stupid questions

There are no dumb questions ... ... any news?

The parts from germany and france has arrived, still waiting for the Chinaware

joshuadenmark wrote:[...] still waiting for the Chinaware

In case the 16Kx4 SRAM is still missing, drop me a PM.

Thanks for your kind offer Mike

All components has arrived, but private circumstances are eating up my spare time (=retrofun). But my stuff are soon too be available and setup in my retro man cave

At this time of the year (download) ...



... it's best to sit in a warm lodge with all the cold snow outside.

... giving credit to the photographer, Christian Frumolt from Aalen, Germany. This is the Emerald Lodge, located in the Yoho National Park, Canada.

Wow! Thats a really great picture.. maybe I need to modify one of my 5 Vic's..