2064 ><x4B-2,12HL44/****)/) "LCyX;?)/0`/ "--.ũ/-/0-. q/ "--.909/L" q/-/0-.9L,7X L,/--e-.i./e/0i0L`;4096 POWDERERED TOAST!G@"@㠥/````` p`@2 @@@P@@" @% @ "@%``%@@@@#@@!"@@1 @@`А`@@`.` @```0P` @` @/````p @@!@" * @ @@ #9@  @` @@```.`%`/)``!"@"+`#*а`&`"`4`0```@"``$`#!`@* @`@!`(@@ ` &```$@@ -`ppА!p)pPp*`` P@@)pp$@@$ !&@!%А!䐣!`!`&&pp"〣-p`@@@@P !p"``%%`#p - @ @ @@@+@@ @@P(@ `LLLLLwօӅѩЩҩ  Ѝ! x ܍ ܭЍ ЭЍ)ЭЍ ЭwXLH)=I)*2iЭI)*a]i9ЊHi Ѝhh(L1'Н؝ٝڝ`цֆөҩ  #LH 4 4) hL()`Ӧ֥i(҅h ` LʆL)H:   LҥjHiheѐPh`ɅɆΆɇ !Ɉ !L L7- L`  L` 뢣  )ɀ LB  L&)  L& x ܎ЭЎЭX `-*- MORE -*- ,`This is Powdered Toast Man on an 80-column screen. I call it Flash-80 because I can't think up a cryptic acronym for it. _ !. $_ . #I F 'T H I S #I S %T O O )H A R D '/# /_\_ )|\_|/__/| #T O )R E A D , %T R Y :T U R N I N G | |/o\o\ +/ / \/ \ \ %T H E 1C O N T R A S T , #O R 2U S E | \\_/_/ -/__|O||O|__ \ !A 'M O N O -M O N I T O R .T H A T / |_ !| /|/_ \_/\_/ _\ | %H A S !A 'V E R Y 7S T A T I C | ||\_ ~| %| | (_&) | || /D I S P L A Y . %U S E /F 1 - F 7 | |# \/ #\/\_)/\__/ // #T O +C H A N G E 2C O L O R S . | |!_ #(_/ ,|| \// | !| "|| `/If you can read this, then I guess you || | !| `7||\ care how it's done. Simply put, you are ||_ \ !\ `9//_/ seeing two 40-column screens being inter- \_| o| !\_"// `-laced, much like an old Amiga's 640x400 /\_!/ `=__ || __|| screen is really a pair of interlacd 640x200 / |"__ !(_!(_`.) screens. Hold the SHIFT key for a glimpse !(_#)_) aat what's REALLY happening. Push RETURN to scroll down one line, or SPACE to scroll down one screen. Greetings to Style, coolhand, XmikeX, Tron, the bots, Banzai, Blob, and groups like F4CG, Byterapers, anyone who still programs NTSC, etc. etc. etc." -m I know what you're thinking. "This is hard as hell to read! There are millions of other 80-column routines out there that work perfectly well! Why would anyone want to put up with this?" Well, I'm glad you asked, because if Flash-80 did not have its advantages, it would not have been done. Many people who see this can probably tell right away the advantages of using this kind of 80-column routine. (Skip through this if you like, there's some more ASCII art at the end.) As you all know, most Commodore 64's have about 64k of memory, of which about 57k (wild guess) is actually useful for storing data. As it normally goes on a regular 40-column program, 1k is used for memory, and the rest is used for data, while 1k of the video chip is set aside just for colour memory, and the VIC chip quietly takes its character set from ROM which isn't even readily available to the 6510, so you don't have to worry about it. So the CBM's standard screen editor uses a grand total of 1K (2K if you count the colour memory, which isn't good for anything else anyway), and a few zero-page registers. But 80-column programs eat up resources like nobody's business. Storing the font can take anywhere from 1k to 4k of memory. The screen itself is the big resource hog. 8k of memory must be allocated to the hi-res screen itself. And since it is a hi-res screen, you can't use the 1K of chip colour memory; you have to allocate 1k of precious workspace to colour storage while that chip memory goes to waste. So now we're using about 10k of memory (over 15% of your Commodore's total storage) or the screen. This spells trouble for text editors, or any program which might like to have some breathing room. Another consideration is speed. To draw a character on an 80-column screen, after calculating its position, you have to fetch and plot eight nybbles from your font onto the screen. EIGHT. As if this, in itself, weren't a hassle, there is often work involving bit shifting and multiple sweeps of Boolean math on every byte. This spells trouble for high-speed terminal programs like Novaterm. What makes Flash-80 preferable is that it takes up, probably, a MAXIMUM of 6k, if you wanted to have separate uppercase and lowercase fonts. If you use only one font, it will only take 4k of usable memory! And in this demo, since I didn't use any reverse characters, I'm using only 3k of memory! It's faster, too. Instead of having to muck around with bit shifting or intense Boolean math, I just find a spot on the screen and POKE to it, almost like a normal screen. The difference is, it's really two screens, but that's pretty easy to compensate for. As one can easily tell, I have to store the odd-columned characters on one screen, and the even-numbered characters on the other, but the calculation for that is just a few instructions. Scrolling and clearing is also faster, since the machine only has to move or clear 2k of memory instead of 8k. Be warned, it is interrupt-driven. The interrupt is a very fast one, but it must be set at a raster-line. It has to execute exactly 60 times per second to remain consistent, though one could try it with the normal IRQ system. Here is a memory map of what I did for this beastie.$ )0400-0800 `,Screen 1 memory A C E G I K M O Q S U W Y )0801-08xx `!BASIC program-starter (SYS2063) )0900-0c00 `!4x8 80-column font (768 bytes!) &0c00-10 /Screen 2 memory d3B D F H J L N P R T V X Z (WARNING: This is a very boring paragraph) I could have made a more extensive font, with reverse characters and CBM graphics but I decided to go another way. I only mapped the low ASCII character set, 96 characters total, and mapped them according to their actual ASCII values so I didn't have to do any bit-shuffling. (Both the Atari and Commodore 8-bits have different ASCII codes than screen codes! Why is that?!) Doing this the way I did, I achieved several things: first, my display driver was simplified a bit; also, I was able to edit this text file using my 386. And as an added bonus to these little conveniences, the font takes up 768 bytes total, out of the 2048 made available to me. I was able to store my font in 0900-0bff, leaving 0800-0900 available for BASIC and/or other data, and put the second screen at 0c00 where the reverrse characters would normally be. This leaves huge amounts of contiguous memory for me to enjoy. I could have put reverse characters at 0c00 and moved Screen 2 up to 10n5, but I wasn't going to use them, so why bother? Okay, that paragraph is over. Now we need to consider our options: What could we do to, or with, this routine? Flash-80 has already been done on the Atari 8-bit with Clay Haliwell's FlickerTerm-80. He came up with the idea sometime before I did, but didn't tell anyone aside from a mysterious message in a local Atari board saying he had an idea for an 80-column driver that was as fast as the Atari's 40-column driver, even when clearing and scrolling. I thought he was going to do some tricks with display lists (an Atari feature I won't go into) and left my thoughts. A while later when I was thinking and came up with Flash-80, I left Clay some mail asking if this was his brilliant new 80-column driver's main idea. He said it was, and he was actually only a few weeks away from releasing FlickerTerm. I was relieved that the idea wasn't reaelly mine, since I would never be able to get anyone to program something useful with Flash-80, and Haliwell could actually program well enough to write a terminal program with it. Flickerterm-80 is one of the more popular VT-100 emulations available for the Atari, and is also less buggy than most implementations so far (since Haliwell had the drive to actually program beyond the first version!) The fact that this has been done for quite some time on another platform suggests that any platform with raster or vertical blank interrupts could implement this mode. Vic-20 machines could manufacture Flash-40 out of this, which is very fortunate due to its cramped memory conditions. First of all, the possibility of reverse characters is real. Just map the characters like you normally would, just use the first 4 bits. Reverse characters will not be possible on systems with 128-character fonts like the Atari 8-bit, because a hardware reverse character will hang over the next character. Color is possible, but it doesn't look very good unless you stick to grayscale colors. Also, since the C64 cannot flip between color pages as it can with screen pages, color resolution will be the same as Novaterm's (even-numbered columns must be the same color as their odd-numbered neighbor). Theoretically, one could keep two color pages in conventional memory and copy each one to color memory on every frame, but who would want to? (This would be unnecessary on the VIC-20, which CAN flip color pages, or so I've heard.) Applications of Flash-80 are innumerable. (I think that's a word?) It has already been implemented in Flickerterm, as I have mentioned. The low memory usage makes it perfect for use in text editors, spreadsheets, or databases. One could put both PETSCII sets in and replace the screen editor with it, allowing one to program in BASIC in 80 columns, not unlike Compute!'s Screen-80 program. It would be even more useful as a CRT device for other programming languages. Wouldn't C programs be easier to port to an 80 column screen? I'm leaving all of this up to the other programmers. If anyone out there is good enough to program an application, it should be trivial to throw together a little font, put a tiny interrupt in their program, and program their screen functions for the new screen. One should also put in provisions to change the screen colors, as I did, but possibly with more thought, such as only cycling through gray scales. I was going to include some ASCII art here, but I don't care to see how it looks at this time. In conclusion, rip this routine and use the hell out of it! .$wrap.( E