Character ROM replace with RAM?

[Mike]

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.

Does 28x32 now mean 28 columns x 32 rows or 28 rows x 32 columns?

Of course all characters that aren't used for the screen(s) are available for the characters. Like thus:

screen 1: screen @ $1000..$137F, character base @ $1000, codes: 0..111 overlap with screen (unusable), 112..255 for background+sprites.
screen 2: screen @ $1800..$1B7F, character base @ $1800, codes: ... see above.

This assumes fully double buffered character sets, but gains you at least another 16 extra characters. This overlapping technique is also used by MINIGRAFIK: codes 0..14 overlap with the screen, the bitmap is addressed by codes 16..255. The 'leftover' address range of $10F0..$10FF (which would be addressed by code 15) is repurposed to hold a BASIC stub during the operation of @SAVE.

[beamrider]

32 columns...

Thanks, hadn't considered that they could sit at the same base address, there may be some mileage in that approach, will have a play...

46 chars for sprites is certainly better than 30!

Edit: I might also be able to get the background count down slightly by making a few tweaks reducing the number of unique scroll-pairs.

[tokra]

32 columns...

This seems like overkill. A PAL VIC-20 on standard TV will only display a resolution of x=208 (26 columns) and even then you may already be in the overscan-area.

What Mike and I used for Maxigrafik at 208x256 (26 columns x 32 rows) was based on HyperGraphics from March 1986. I think some games also used that resolution.

If you add a column left and right to hide scrolling you would end up at 224 x 256 (x by y) or 28 columns by 32 rows.

[beamrider]

Just checked it's actually set at 31 columns, if I reduce it to 30 I can see scrolling artefacts in VICE, maybe not visible on proper HW though.

edit: that might be my scrolling routine which is sometimes temporarily disrupting 2 columns before correcting itself..will have to investigate.

[Vic20-Ian]

@Vic20-Ian:

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(

Have you seen Jeff using a ram expansion? He might not use this either as it moves away from the machine we know and love.

The majority of Vic20 users don't want to build your mod into their standard machines but might be willing to swap a rom for ram if the solution was not too intrusive and reversible.

I would prefer that option for a weekend of experimentation.

I think vfli is off topic here as the topic was more UDG on a standard Vic.

[Mike]

Have you seen Jeff using a ram expansion? He might not use this either as it moves away from the machine we know and love.

The majority of Vic20 users don't want to build your mod into their standard machines but might be willing to swap a rom for ram if the solution was not too intrusive and reversible.

I would prefer that option for a weekend of experimentation.

I think vfli is off topic here as the topic was more UDG on a standard Vic.

Go trolling elsewhere.

[beamrider]

I've managed to clean up and optimise my smooth scrolling routine and got the dimensions down to a 28x28 which just about hides the x-axis scrolling on a commodore 1701 monitor.

This leave 60 free for sprites [98 overlap, 98 for background] which isn't a huge amount but some games may well be possible...