Denial

Would it be possible to swap out the Character ROM for RAM (and then populate from disk/tape)?

beamrider wrote:Would it be possible to swap out the Character ROM for RAM (and then populate from disk/tape)?

Sure, that's possible. I assume you want a solution that would work without expansion ram, otherwise you could just put your new character set there and point the VIC to it.

You would need to build an adapter board, and tap into the R/W line. If you used an NVRAM then the contents would not be lost when the machine is turned off. If you use normal RAM you won't have a character set on bootup, so you'd probably want to keep the existing ROM and then have some way to select RAM via software. That way the machine would stay compatible and have a proper startup screen.

Steve

Thanks.

I believe the Vic chip can't be pointed at external memory otherwise - yes it would be easier to have it as a cartridge.

sjgray wrote:I assume you want a solution that would work without expansion ram, otherwise you could just put your new character set there and point the VIC to it.

My advise for you is to just try it out and see your program fail miserably.

beamrider wrote:Would it be possible to swap out the Character ROM for RAM (and then populate from disk/tape)?

Any reason you want to do this other than just for the sake of it?

Putting a RAM into the character ROM socket to get any UDGs was only necessary on the PET, where one couldn't point the character generator elsewhere (to RAM).

An obvious answer would be a full 3.5k game with UDG not taking up game code space.

With my current scrolling routine and a reasonably complex background (using 2 x 98 chars)and using double buffering and shifted characters I am left with only about 30 chars for sprites (2 x 1k for large screens 2 x 1k for character banks). If I could redefine ROM characters the number of characters available for sprites would increase by 128.

O.K.

If an extra 3K RAM for graphics data would be sufficient, try out the internal RAM expansion of my VFLI mod.

This makes the entire lower 8K (i.e. BLK0 at $0000..$1FFF) accessible to VIC, especially $0400..$0FFF - which would not work with an external +3K RAM expansion indeed.

Thanks Mike, but I think that a mod requiring soldering would put people off more so than just replacing a socketed ROM. But thinking about it, not all Vic character ROMs are socketed are they so maybe the idea is a non-starters anyway...

@Vic20-Ian:

Vic20-Ian wrote:An obvious answer would be a full 3.5k game with UDG not taking up game code space.

Because exchanging the character ROM with RAM is oh so much easier done than adding a normal RAM expansion, running the code there and using the internal RAM for UDGs as it's normally done. Yeah. m(

beamrider wrote:I think that a mod requiring soldering would put people off more so than just replacing a socketed ROM.

The character ROM isn't socketed in my VIC-20.

In any case it's a mainboard mod. That's not everyone's cup of tea. And modding the mainboard for just a single application is a very unlikely thing people will do.

Edit: I saw you came to the same conclusion. Well...

Edit 2: If you replicate my VFLI mod, I could at least test your game.

thanks, but I think most people would just end up running any such game requiring these soldering mods in VICE, in which case I may as well just dev for the PC

beamrider wrote:thanks, but I think most people would just end up running any such game requiring these soldering mods in VICE, in which case I may as well just dev for the PC

But the VIC-20 is a PC? Or am I missing something?

(j/k...I knew what you meant)

beamrider wrote:With my current scrolling routine and a reasonably complex background (using 2 x 98 chars)and using double buffering and shifted characters I am left with only about 30 chars for sprites (2 x 1k for large screens 2 x 1k for character banks). If I could redefine ROM characters the number of characters available for sprites would increase by 128.

You could try double-use of the background characters with essentially this method:

screen1: screen @ $1000, charset @ $1400 (to $1BFF), background characters mapped at 128..255, sprites at 0..127
screen2: screen @ $1200, charset @ $1800 (to $1FFF), background characters mapped at 0..127, sprites at 128..255

That'd also allow for doubly buffered colour RAM, BTW.

Thanks Mike, but doesn't that limit the screen to 512 bytes or am I missing something ?

My screens are 28 X 32 (896 bytes).

Yes, of course this limits the screen size to effectively the standard screen size.

Please keep in mind though, that - 1. NTSC screens won't show much more than 22x23 and 2. the colour RAM can only be double buffered with a screen max. size of 512 bytes.

Even 28x32 is over the edge for most PAL monitors and TVs.

Yes, well I was planning to "forget" about NTSC and use a 4 colour mutli color scheme. This also reduces the workload as the color ram doesn't need to be scrolled.

Edit: 2 of the 32 cols are deliberately off-screen to contain the scrolling detritus.