I didn't have my VIC-20 long enough to see things like this, but used similar software on my Radio Shack Color Computer to get upper/lowercase and wider screens. It makes sense the VIC had something to do this. I look forward to experimenting on a TheVIC20.
I disassembled the 'fat-40' program with HESMON about a year ago. One of the most intereting things is that there is part of a game left in it. The programmer was scandinavian(finnish) and the game fragment is from a type in version of 'seawolf' presumably from some magazine or written by the same author. I made an NTSC patched version which can be found on the denial forums for those of you VIC 20 users in NTSC lands. Getting it to work was very difficult. He encoded a basic program poke in a separate location in memory to the VIC registers controlling the screen location. This is included in the load and the machine language relocates basic and then jumps back into basic and executes the poke, then clearing the screen upon completion. This is why the screen on load appears to dance around. I eventually found the poke by realizing it wasnt done in ML and then interpreting the final start of basic pointer that was to be set, without running the program. Otherwise it erases itself and you'll never find it.
That is interesting and surprising considering how little memory the Vic has that there would be anything extraneous in it. I couldn't find out who wrote it. The earliest reference I found to it in print was from Ahoy! Magazine, issue 10, 1984: archive.org/details/ahoy-magazine-10/page/n43 Do you know the name of the Finnish author?
@@TechTinkering Unfortunately no. The author clearly indicated 1983 as the working date. I was equally surprised as you can imagine to see waste code. You can see it for yourself with the hesmon monitor though using the interpret command. I also found it fun because my initials are identical. However, I am not the PL in question. Sadly, the author has not come forward. Since the later magazine program was clearly a copy adapted for NTSC, we don't even know who made this tech marvel. I was just happy to bring it to people in the states. I am also working on the armalite collection. I have patched almost every game up to the letter G now to work on NTSC televisions. When I am done, I wonder what I should do with my work...upload it to armalite? Heh. Not sure...In any case, At least I will get to play these on my ntsc television. (perhaps Arma could make an ntsc section?) not all of the games are incompatible. Some are... Some i could not figure out. But most are patched and ready to work on NTSC.
(I am working in alphabetical order through the armalite vic 20 games collection database) a lot of them have primitive copy protection so it is slow going. I also documented the decoding and patching in real time! Which is something I have seen none other do. My hope is that the end product will be a 6502 coding teaching tool for abstract programming as well as a fun project. In fact, I cant remember which gsme off the top of my head, but in one game the fat 40 program solved the copy protection! Somce the printing is slower i saw a line print and then delete itself. The entire experience is however, recorded in my notes for that particular game. I really hope that some medium occurs where I can impart this, among other voyages of discovery for other fledgling coders.
Your channels have great videos. Very interesting retro tricks for the VIC-20, which I have one on my desk at home! Subscribed! The VIC-20 is featured in John Wick II, btw!
After reading the accompanying article, Ive made a patched version of PET Loader for NTSC Vic 20s. What I like best about it is that it is basic compatible. The 83 version jams when i try to run programs and until now, that was my only 40 column software on the vic...i also had patched that one to NTSC a few years ago no doubt it is floating round out there. Before that I had no other knowledge of any other software 40s like the compute! Version from '84. By the way, this program also has tons of wasted space. The entire A000-AFFF Section is virtually blank after the cartridge header. I was considering adding a few mods onto this like a basic wedge that checks for pet pokes and automatically changes them, and a boot screen that is more "pet like" than the current version. I am not so sure about the feasability of the former, but the latter could be done in a day.
In addition there is a better "the big one" out there. It is on the denial forums and it is called "nice text" if memory serves. It goes up to i think 29 columns on the pal systems with existing char set.
@@peterlamont647 Thanks for letting me know about it. I've just been looking at the thread in the forum and the discussion around it was quite interesting.
Dear TechT, Thanks for the thoughtful comparison of so many great font-changing programs for the Friendly Computer! I love your references to historical articles referencing or including these programs! I’ll be testing these with my all my VIC-20 word processors. I’m especially curious about The Big One, since it seems to really honor the spirit of our old friend VIC the most. What you have seems to be a demo. I’ll start watching for the full Kingsoft product. Do you think it will work on an NTSC machine? I work with vintage equipment.
I'm glad you liked it. There is a version of VIC 40/FAT-40 and PET Loader for NTSC and Screen-40 is NTSC by default, however unfortunately I have not come across a version of Super Screen for NTSC. The Big One in particular has to be PAL because in my experiments with different screen sizes on NTSC systems the best I could reliably get was 24x28 not the 25x30 of The Big One. If you do find a version of Super Screen for NTSC I'd love to hear.
Is the delay from typing to screen because of the program or because of VICE? That delay is really bad if you were using it for a game or something that requires quick action.
The delays are because of the programs. Some of them are partially or entirely written in Basic. Even those written entirely in assembly language will have a bit of a delay because it takes quite a lot of processing to display like this. It's fine for terminals, text adventures, etc but you're right it would be too slow for a game requiring quick screen updates.
I noticed VIC-40/FAT-40 is the only one that has 25 rows like the PET. Screen-40 and Super Screen have only 24 rows. I couldn't tell from your video how many rows PET Loader has. VIC-40/FAT-40 is really the only contender here. Last year I ported a BASIC PET game called Bio-Terror! to the VIC-20 using VIC-40/FAT-40. Only had to adjust a few lines of the code.
I hadn't really noticed this before. I just checked and it is 25 rows which makes sense considering it was trying to add some sort of compatibility with the PET.
I was thinking about this and if you expand the screen to 30 column size and then do a character set based on 6x8 pixel character blocks you could do a pretty nice 40 column mode without wasting precious screen estate on a border.
It's interesting playing with the different possible formats. One problem with 30 columns is that it would exclude most of our friends using NTSC. However, 24 columns using 6x8 characters would produce a nice 32 columns or using a 4 bit wide font we could even have 48 columns.
@ungratefulmetalpansy True but 4x8 pixel characters are naff, like the software 80 column mode of C64 so this would be better for text based game with short window for text and static standard VIC graphics in a larger window. perhaps. Was really more amazed it is possible as the C64 always has similar borders for bitmap graphics displayed
Does anyone know how to decode VIC-20 serial numbers to find out the machine's age? I want to see how old my unit is because I got it secondhand, and I don't want to miss its 40th birthday.
Oh :( From your video I though that compatibility was not much of an issue with the FAT-40 variant. Do you mean Basic programs having compatibility problems, or machine coded programs? I though that maybe most machine level programs would run, because they reset most of the RAM anyways. If that's not the case: Wiuld it be to ohard, to try try adding an automated recognition routine for machine code autoloaders, that reset all the modifications to normal ROM state, if there's a machine coded program being LOADed? Then only Basic programs could make trouble and would require specific fixes in some cases, but that's a thing that 'normal' users could fix easily themselves, especially with a great 40 column screen :) The usage of a cartridge for this doesn't seem so attractive to me, because the cartridge slot of the VIC20 usually is already taken by the RAM expansion or other tools. Everytime I see my old VC20 in the little retro showcase I have, think 'hey, I could sit a bit and play or do some fun coding on my old VC20'! And then I am pushed back, by the 22 column screen, the moment I power it on. :( Possibly the Penultimate cartridge would be an alternative solution to this, giving RAM expansion and program loading possibilities at once?
@@elmariachi5133 There are two many what ifs to maintain any sort of compatibility with existing Basic and machine language programs. It's standard practise, even in Basic, for programs to directly access memory, to move screen maps around, to use other low-level facilities of the Vic, etc It would be a constant up hill battle trying to anticipate these.
Almost every basic program has pokes. In a pure interpretive environment you would not allow this. However, if you want a useful program with a limited interpreter, you must allow the programmer to escape the interpreter and cheat a bit. This is what poke and peek statements accomplish. The downside is that if any of these locations change....the program simply doesnt work at best, or at worst jams the processor. Since commodore basic was so sparse in its commands(no graphics or sound commands whatsoever) nearly every program had to escape the interpreter to achieve anything useful.
@1000 Subs with just Playlists I use vokoscreen, which works really well as I can select an area of the desktop, an application or the whole desktop to record.
I didn't have my VIC-20 long enough to see things like this, but used similar software on my Radio Shack Color Computer to get upper/lowercase and wider screens. It makes sense the VIC had something to do this. I look forward to experimenting on a TheVIC20.
I disassembled the 'fat-40' program with HESMON about a year ago. One of the most intereting things is that there is part of a game left in it. The programmer was scandinavian(finnish) and the game fragment is from a type in version of 'seawolf' presumably from some magazine or written by the same author. I made an NTSC patched version which can be found on the denial forums for those of you VIC 20 users in NTSC lands. Getting it to work was very difficult. He encoded a basic program poke in a separate location in memory to the VIC registers controlling the screen location. This is included in the load and the machine language relocates basic and then jumps back into basic and executes the poke, then clearing the screen upon completion. This is why the screen on load appears to dance around. I eventually found the poke by realizing it wasnt done in ML and then interpreting the final start of basic pointer that was to be set, without running the program. Otherwise it erases itself and you'll never find it.
That is interesting and surprising considering how little memory the Vic has that there would be anything extraneous in it. I couldn't find out who wrote it. The earliest reference I found to it in print was from Ahoy! Magazine, issue 10, 1984: archive.org/details/ahoy-magazine-10/page/n43
Do you know the name of the Finnish author?
@@TechTinkering Unfortunately no. The author clearly indicated 1983 as the working date. I was equally surprised as you can imagine to see waste code. You can see it for yourself with the hesmon monitor though using the interpret command. I also found it fun because my initials are identical. However, I am not the PL in question. Sadly, the author has not come forward. Since the later magazine program was clearly a copy adapted for NTSC, we don't even know who made this tech marvel. I was just happy to bring it to people in the states. I am also working on the armalite collection. I have patched almost every game up to the letter G now to work on NTSC televisions. When I am done, I wonder what I should do with my work...upload it to armalite? Heh. Not sure...In any case, At least I will get to play these on my ntsc television. (perhaps Arma could make an ntsc section?) not all of the games are incompatible. Some are... Some i could not figure out. But most are patched and ready to work on NTSC.
(I am working in alphabetical order through the armalite vic 20 games collection database) a lot of them have primitive copy protection so it is slow going. I also documented the decoding and patching in real time! Which is something I have seen none other do. My hope is that the end product will be a 6502 coding teaching tool for abstract programming as well as a fun project. In fact, I cant remember which gsme off the top of my head, but in one game the fat 40 program solved the copy protection! Somce the printing is slower i saw a line print and then delete itself. The entire experience is however, recorded in my notes for that particular game. I really hope that some medium occurs where I can impart this, among other voyages of discovery for other fledgling coders.
Your channels have great videos. Very interesting retro tricks for the VIC-20, which I have one on my desk at home! Subscribed!
The VIC-20 is featured in John Wick II, btw!
Thanks. More coming soon!
This is amazing. Why didn't the Compute! people tell us this thing existed?!
Very clever, really. I used the 40 column Terminal program back in the day and it worked quite well.
After reading the accompanying article, Ive made a patched version of PET Loader for NTSC Vic 20s. What I like best about it is that it is basic compatible. The 83 version jams when i try to run programs and until now, that was my only 40 column software on the vic...i also had patched that one to NTSC a few years ago no doubt it is floating round out there. Before that I had no other knowledge of any other software 40s like the compute! Version from '84.
By the way, this program also has tons of wasted space. The entire A000-AFFF Section is virtually blank after the cartridge header. I was considering adding a few mods onto this like a basic wedge that checks for pet pokes and automatically changes them, and a boot screen that is more "pet like" than the current version. I am not so sure about the feasability of the former, but the latter could be done in a day.
In addition there is a better "the big one" out there. It is on the denial forums and it is called "nice text" if memory serves. It goes up to i think 29 columns on the pal systems with existing char set.
@@peterlamont647 Thanks for letting me know about it. I've just been looking at the thread in the forum and the discussion around it was quite interesting.
I had a vic 20. This is great! I subscribed immediately! Well done!
A great video, as always.
Thanks Alexander. I'm planning more on the VIC-20, it really is a great little machine.
Dear TechT, Thanks for the thoughtful comparison of so many great font-changing programs for the Friendly Computer! I love your references to historical articles referencing or including these programs! I’ll be testing these with my all my VIC-20 word processors. I’m especially curious about The Big One, since it seems to really honor the spirit of our old friend VIC the most. What you have seems to be a demo. I’ll start watching for the full Kingsoft product. Do you think it will work on an NTSC machine? I work with vintage equipment.
I'm glad you liked it. There is a version of VIC 40/FAT-40 and PET Loader for NTSC and Screen-40 is NTSC by default, however unfortunately I have not come across a version of Super Screen for NTSC. The Big One in particular has to be PAL because in my experiments with different screen sizes on NTSC systems the best I could reliably get was 24x28 not the 25x30 of The Big One. If you do find a version of Super Screen for NTSC I'd love to hear.
Is the delay from typing to screen because of the program or because of VICE? That delay is really bad if you were using it for a game or something that requires quick action.
The delays are because of the programs. Some of them are partially or entirely written in Basic. Even those written entirely in assembly language will have a bit of a delay because it takes quite a lot of processing to display like this. It's fine for terminals, text adventures, etc but you're right it would be too slow for a game requiring quick screen updates.
I noticed VIC-40/FAT-40 is the only one that has 25 rows like the PET. Screen-40 and Super Screen have only 24 rows. I couldn't tell from your video how many rows PET Loader has. VIC-40/FAT-40 is really the only contender here. Last year I ported a BASIC PET game called Bio-Terror! to the VIC-20 using VIC-40/FAT-40. Only had to adjust a few lines of the code.
I hadn't really noticed this before. I just checked and it is 25 rows which makes sense considering it was trying to add some sort of compatibility with the PET.
Cool! I'm your new subscriber! I also really like Commodore computers!
Welcome aboard, you're in good company.
@@TechTinkering look here! ua-cam.com/video/LvNUEn_N7Eo/v-deo.html
I was thinking about this and if you expand the screen to 30 column size and then do a character set based on 6x8 pixel character blocks you could do a pretty nice 40 column mode without wasting precious screen estate on a border.
It's interesting playing with the different possible formats. One problem with 30 columns is that it would exclude most of our friends using NTSC. However, 24 columns using 6x8 characters would produce a nice 32 columns or using a 4 bit wide font we could even have 48 columns.
@@TechTinkering The user defined resolution of the VIC-I is something that really should have been in the VIC-II as well I think.
@ungratefulmetalpansy True but 4x8 pixel characters are naff, like the software 80 column mode of C64 so this would be better for text based game with short window for text and static standard VIC graphics in a larger window. perhaps. Was really more amazed it is possible as the C64 always has similar borders for bitmap graphics displayed
I’ve got program “40 colonne” on tape (italian piracy newstand) that is like “Super-Screen”.
When I was looking into this it turned out that there were lots of attempts. I wonder if only the best survived or if we have lost any gems?
Does anyone know how to decode VIC-20 serial numbers to find out the machine's age? I want to see how old my unit is because I got it secondhand, and I don't want to miss its 40th birthday.
Man when you see that you REALLY realise what a jump the C64 was
Could one make a patched VIC20 ROM with FAT40 included?
In theory, but it would make the VIC-20 incompatible with most of its software. A better alternative could be having it on cartridge like PET Loader.
Oh :( From your video I though that compatibility was not much of an issue with the FAT-40 variant.
Do you mean Basic programs having compatibility problems, or machine coded programs? I though that maybe most machine level programs would run, because they reset most of the RAM anyways. If that's not the case: Wiuld it be to ohard, to try try adding an automated recognition routine for machine code autoloaders, that reset all the modifications to normal ROM state, if there's a machine coded program being LOADed?
Then only Basic programs could make trouble and would require specific fixes in some cases, but that's a thing that 'normal' users could fix easily themselves, especially with a great 40 column screen :)
The usage of a cartridge for this doesn't seem so attractive to me, because the cartridge slot of the VIC20 usually is already taken by the RAM expansion or other tools. Everytime I see my old VC20 in the little retro showcase I have, think 'hey, I could sit a bit and play or do some fun coding on my old VC20'! And then I am pushed back, by the 22 column screen, the moment I power it on. :(
Possibly the Penultimate cartridge would be an alternative solution to this, giving RAM expansion and program loading possibilities at once?
@@elmariachi5133 There are two many what ifs to maintain any sort of compatibility with existing Basic and machine language programs. It's standard practise, even in Basic, for programs to directly access memory, to move screen maps around, to use other low-level facilities of the Vic, etc It would be a constant up hill battle trying to anticipate these.
OK, then I probably need to buy one of these penultimate cartridges one day. Thank you for the information! :)
Almost every basic program has pokes. In a pure interpretive environment you would not allow this. However, if you want a useful program with a limited interpreter, you must allow the programmer to escape the interpreter and cheat a bit. This is what poke and peek statements accomplish. The downside is that if any of these locations change....the program simply doesnt work at best, or at worst jams the processor. Since commodore basic was so sparse in its commands(no graphics or sound commands whatsoever) nearly every program had to escape the interpreter to achieve anything useful.
Are you using an emulator or hardware video capture?
I'm using an emulator: VICE.
@1000 Subs with just Playlists I use vokoscreen, which works really well as I can select an area of the desktop, an application or the whole desktop to record.
that does not sound like a vic20 keyboard
No, it's my trusty UNISYS PCK104-SKB / KB-6926. I've had it for over 20 years and still use it everyday via an AT to PS/2 adaptor.