Leif asked me to post this here.
While working on putting my VIC-20 on the Internet, I decided to obtain the Compute's Gazette Screen-40 application to make the screen less jarring.
However, I found that Screen-40 locked up the machine when I used the stock RS-232 routines.
I debugged the code and found the issue.
SCREEN-40 redirects all the regulars vectors, and redirects CHROUT to $20be. It checks to see if the current device is screen. If not, it bne to 20d2, where it does a jmp to $ff85. That last address is in error. The original CHROUT routine performs the same check, but branches to F285 if not screen. So, changing 20d2 to jmp f285 fixes the issue.
To fix quickly, simply load and run SCREEN-40, then add pose 8404,242 to fix the issue.
My post about getting the VIC online is elsewhere here.
Jim
Screen-40 bug fixed
Moderator: Moderators
Hi,
I was thinking about if it's possible to use other screen resolutions like 27x32 with my VIC and the built-in system routines.
Looking around in the forum brought up this very interesting topic - but where can I find the mentioned Screen-40 application? I would like to look at the source to see if I could use this for my idea...
I was thinking about if it's possible to use other screen resolutions like 27x32 with my VIC and the built-in system routines.
Looking around in the forum brought up this very interesting topic - but where can I find the mentioned Screen-40 application? I would like to look at the source to see if I could use this for my idea...
The logical line lengths are stored as a table in the Kernel ROM, but somehow copied down to RAM. I'm not sure if it is sufficient to change the RAM pointers, but otherwise you need a different ROM chip to use a different line length with the built in editor and PRINT routines.
Screen-40 I believe patches the cursor scrolling and PRINT routines to their own. If I'm not mistaken, it sets up a screen that is 20x12 double-height (8x16) custom characters, and then plots pixels like a hires bitmap.
There were several such programs, both commercially sold and freeware. I don't know which is better, but here are a few ones to try:
http://www.ftp.funet.fi/pub/cbm/vic20/u ... /index.htm
Notice that due to the custom character bitmapped screen consumes most or all of the unexpanded memory, you need +3K or more commonly +8K to hold the program and of course any application you load into it.
Screen-40 I believe patches the cursor scrolling and PRINT routines to their own. If I'm not mistaken, it sets up a screen that is 20x12 double-height (8x16) custom characters, and then plots pixels like a hires bitmap.
There were several such programs, both commercially sold and freeware. I don't know which is better, but here are a few ones to try:
http://www.ftp.funet.fi/pub/cbm/vic20/u ... /index.htm
Notice that due to the custom character bitmapped screen consumes most or all of the unexpanded memory, you need +3K or more commonly +8K to hold the program and of course any application you load into it.
Anders Carlsson
Yes, I know them, but I would like to have some sources, if possible. It seems that the Screen-40 application could handle all output redirected through kernal routines, so it should even be possible to create basic programs in 40 columns. But this is really slow because of the bitmap mode, so I thought about using a bigger screen but remaining in character mode.
And I don't want to debug through undocumented assembler code, so I hoped for some sources...
And I don't want to debug through undocumented assembler code, so I hoped for some sources...
I think Groepaz has written a 40x24 mode in C, which compiles with cc65. Dunno about assembly routines though. Have you tried the Perl script "recomment" to disassemble into something almost readable?
The line length and scrolling are quite hard-coded into the Kernal. Not only are there a lot of references to #$16 (decimal 22 columns) everywhere, there is also a table at $EDFD which contains the low byte of the screen address for the beginning of each line, if you understand how I mean.
The entry routine for printing characters, interpreting cursor controls etc is $E742 (SCNPNT) which is called from $FFD2 (CHROUT) -> pointer at ($0326) -> $F27A (CHROTK).
It probably is best to write your own SCNPNT routine, duplicating or calling ROM routines where possible. If you can get hold of a commented ROM dump, it probably helps you a lot. Otherwise, make a copy of the Kernel ROM image, try to replace all absolute references to #$16 (22) to something else and experiment with the emulator.
I just made an alternative Kernal, called "kernal.alt" which at first tried to dynamically adjust line width, but then I found the hard coded table mentioned above and changed it into a 16 column display. It does not work very well, but gives an idea what could be done. Since it is buggy and I'm not planning to try to fix it, ask me if you want a copy.
The line length and scrolling are quite hard-coded into the Kernal. Not only are there a lot of references to #$16 (decimal 22 columns) everywhere, there is also a table at $EDFD which contains the low byte of the screen address for the beginning of each line, if you understand how I mean.
The entry routine for printing characters, interpreting cursor controls etc is $E742 (SCNPNT) which is called from $FFD2 (CHROUT) -> pointer at ($0326) -> $F27A (CHROTK).
It probably is best to write your own SCNPNT routine, duplicating or calling ROM routines where possible. If you can get hold of a commented ROM dump, it probably helps you a lot. Otherwise, make a copy of the Kernel ROM image, try to replace all absolute references to #$16 (22) to something else and experiment with the emulator.
I just made an alternative Kernal, called "kernal.alt" which at first tried to dynamically adjust line width, but then I found the hard coded table mentioned above and changed it into a 16 column display. It does not work very well, but gives an idea what could be done. Since it is buggy and I'm not planning to try to fix it, ask me if you want a copy.
Anders Carlsson
POKE to screen memory is your friend. 
Maybe there exists some do-your-own CHROUT routine somewhere which you could work from. I suppose one of the reasons why there are tables and a lot of hard coded values was to save space. Theoretically they could have put a similar table in RAM and on power on, BRK or something else called a routine that sets up the table based on current settings, but it also takes some valuable space.
Maybe there exists some do-your-own CHROUT routine somewhere which you could work from. I suppose one of the reasons why there are tables and a lot of hard coded values was to save space. Theoretically they could have put a similar table in RAM and on power on, BRK or something else called a routine that sets up the table based on current settings, but it also takes some valuable space.Anders Carlsson
Yes, Pokes can do, but I would like to have Print working - and this would require a patched kernal. Then we could even use the built-in full screen editor with different resolutions...
I'm not sure if it was for saving time, space or just some sort of lazyness not to use a few RAM locations for columns and rows. Maybe nobody even thought about making this configurable. It's the same as with the very pessimistic assumptions for tape or drive timings and so on... There is a lot of room for improvements in the kernal. But the developers had only a limited time for their work, and they did their work very well - just imagine MS would burn their software into ROMS and deliver this to customers - no chance for patches, this would not work
I'm not sure if it was for saving time, space or just some sort of lazyness not to use a few RAM locations for columns and rows. Maybe nobody even thought about making this configurable. It's the same as with the very pessimistic assumptions for tape or drive timings and so on... There is a lot of room for improvements in the kernal. But the developers had only a limited time for their work, and they did their work very well - just imagine MS would burn their software into ROMS and deliver this to customers - no chance for patches, this would not work