I was wondering if anyone has disassembled Fat40 / Screen-40 / SuperScreen and/or has source for them.
I was thinking of doing some text mode experiments now that I have a working vic20 again (and a mega cart) and didn't really want to start from scratch.
I was going to base it on work I already did on 6 char high c64 stuff like this:
http://www.kludgesoft.com/c64/8033comparison.html
I did do a 40x33 program but it is lost amongst my many disks, it was quite good with 8x6 a font, you couldn't really tell the difference from the normal c64 screen.
Thanks.
40 column program source?
Moderator: Moderators
- Mike
- Herr VC
- Posts: 4841
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: 40 column program source?
Hi, Strobe,
Welcome to Denial!
- The main motivation for them is being able to edit BASIC programs in 40 columns. For cross-development I don't need these emulators. And their editor code, like the one in the KERNAL, looks like a mess.
- I want to use 4 pixels wide characters alongside other graphics. I already wrote the necessary display code myselves, look at MINIPAINT for an example.
Greetings,
Michael
Welcome to Denial!
Here's a disassembly of FAT-40, courtesy carlsson.Strobe wrote:I was wondering if anyone has disassembled Fat40 / Screen-40 / SuperScreen and/or has source for them.
Thus far I didn't attempt re-engineering source from these programs, for two reasons:I was thinking of doing some text mode experiments now that I have a working vic20 again (and a mega cart) and didn't really want to start from scratch.
- The main motivation for them is being able to edit BASIC programs in 40 columns. For cross-development I don't need these emulators. And their editor code, like the one in the KERNAL, looks like a mess.
- I want to use 4 pixels wide characters alongside other graphics. I already wrote the necessary display code myselves, look at MINIPAINT for an example.
Greetings,
Michael
Thanks for the replies, I'll stick to my own little experiments then rather than modding those emulation systems. I was hoping I could just 'drop in' my renderer but that seems a little hard.
I was going to try a 5x6 font to see how it looked (should get 40x26), and maybe a simpler 4x6 to start with (which should get 40x32). Of course my math could be wrong, and I don't know if a 5wide font at 40 columns (25 columns) will work on a ntsc vic.
I was going to try a 5x6 font to see how it looked (should get 40x26), and maybe a simpler 4x6 to start with (which should get 40x32). Of course my math could be wrong, and I don't know if a 5wide font at 40 columns (25 columns) will work on a ntsc vic.
If you're interested, I recently came up with a method of sub-pixel rendering which allows 80 columns on an NTSC VIC. I've been working out details for using a 4x6 font for it.
The basic idea is that you use green on black (or some other solid color against black). This creates a checkerboard mask on all of the pixels, making each pixel only half as wide. The mask changes phase by 180 degrees each field, so the sub-pixel grid dithers in position each field.
The bottom line is that each character gives you 14x8 pixels instead of 8x8 pixels. With doubleheight characters, you have 14x16 pixels instead of 8x16 pixels per character. Thus, with a 23x5 screen of doubleheight characters, you get a resolution of 322x80 pixels. Assuming a 4x6 font, you get 80 columns by 13 rows. You waste a border of pixels around the screen, though.
A more efficient layout is a 20x6 screen of doubleheight characters. This yields a resolution of 280x96 pixels, or 70 columns by 16 rows.
An unexpanded VIC would have extremely little RAM left over for the program. The font could be packed into nybble RAM. The screen consumes 20*6=120 bytes (6144-6263). The two fonts consume 1920 bytes each (4224-6143, 6272-8191). This leaves only 128 bytes for the program (4096-4223), plus whatever memory you can scrape up in the first 1K.
More plausibly, some sort of RAM expansion is required.
The basic idea is that you use green on black (or some other solid color against black). This creates a checkerboard mask on all of the pixels, making each pixel only half as wide. The mask changes phase by 180 degrees each field, so the sub-pixel grid dithers in position each field.
The bottom line is that each character gives you 14x8 pixels instead of 8x8 pixels. With doubleheight characters, you have 14x16 pixels instead of 8x16 pixels per character. Thus, with a 23x5 screen of doubleheight characters, you get a resolution of 322x80 pixels. Assuming a 4x6 font, you get 80 columns by 13 rows. You waste a border of pixels around the screen, though.
A more efficient layout is a 20x6 screen of doubleheight characters. This yields a resolution of 280x96 pixels, or 70 columns by 16 rows.
An unexpanded VIC would have extremely little RAM left over for the program. The font could be packed into nybble RAM. The screen consumes 20*6=120 bytes (6144-6263). The two fonts consume 1920 bytes each (4224-6143, 6272-8191). This leaves only 128 bytes for the program (4096-4223), plus whatever memory you can scrape up in the first 1K.
More plausibly, some sort of RAM expansion is required.