antoniovillena escribió:No. The only way is editing the VHDL code and compiling.
Ok. I had better come up with a good arrangement then.
No. These keys require a previous pressing of EXTEND key. For this reason they are marked in yellow.
Understood. So in this case it will require a previous pressing of the CONTROL key. I can live with that.
Ok. I suppose that you'll replace the ROM that makes the 80 columns mode to the original 48K.
SE Basic IV uses similar ROMs. One provides low res (32 col) and the other high res (80 col). For compatibility, the original ROM can be loaded in RAM and paged over the ROM area. This is uncontended RAM so the timing is as per the original machine.
There is something that I don't understand very well. If mode 1 has double resolution than mode 0, is really need to squeeze more the font? That is, you have a 8x8 font in mode 0 that allows you 32 column mode. You can have a 64 column mode, more readable, with fast routines (don't need rotate bytes) and probably you can implement both modes in a single 16K ROM (because they share the font). So why a 80 column mode?
Note: If you need I have a routine that prints strings with 6x8 fonts almost fast as if they were 8x8. The problem is that you'll need 3K of ROM to store the font (instead 768 bytes).
Have you actually tried the 80 column mode? It's very readable (even on a CRT display) because it has its own font with double width stems. I previously wrote an 80 column mode that used pre-shifted definitions, and SE Basic IV is faster. It's not possible to have more than one display mode in a single ROM without branching. That's why the printing in the original ROM is so slow ... because it is constantly having to decide if it's going to the screen or the printer. That's why SE Basic IV's 80 column mode is much faster than the standard ROM's 32 column mode. The main reason for wanting an 80 column mode was to support a proper 80x24 terminal mode. That could be useful for Spectranet, or for running CP/M programs. If you've ever tried using CP/M in 64 columns with screen flip on the +3 you'll know what an awful experience it is. The way the mode works, the screen is stored in bank 7 which means some existing software will run in that mode with only minor modification for line endings. And you also get the benefit of being able to load a code page in bank 5 that gives you full 8-bit ASCII printing. A further consideration is that if esxDOS gets long filename support, you're going to be really glad to have an 80 column mode.
