32-line BBC micro sized screen type-in can be downloaded from:
http://www.cpctech.org.uk/bigscreen32.zip
Looks like a complicated piece of programming trickery, I tried it out on CPCEMU15 though it didn't really work, I was a even more surprised when RWCPC produced the same result (cause I think it can handle some demos).
I hope you don't mind, I've thrown it to the WebCPC which seems to emulate the effect it quite, guess there wasn't any small demo programs which should demonstrate the effects of the program?
Quote from: arnoldemu on 22:08, 11 August 10
32-line BBC micro sized screen type-in can be downloaded from:
http://www.cpctech.org.uk/bigscreen32.zip (http://www.cpctech.org.uk/bigscreen32.zip)
Nice demo to show that it can be done for basic, however there are some drawbacks:
- CAT makes screen flickering
- COPY cursor can't be used properly (mostly not)
- less than 16 KB of free space!!!
- Can't load a BASIC prog of 12 KB -- memory full :-(
I had the same problem loading a small BASIC program with returned Memory Full. I got around this by doing a NEW, though I suppose the real issue here is it resides so low in memory overwriting will cause problems. Guess it's one of those things that if you've got an extra 64k to poke the program into one of the extra banks? ???
Well, it uses two 16 KB blocks or RAM: The usual screen (&C000-&FFFF) and the block between &4000 and &7FFF. It can't use the 0-3FFF block, because it contains the restarts. And it can't use &8000-&BFFF, because it contains part of the CPC-OS. And since the CRTC can access only the first 64 KB, you can't use the expansion RAM as second screen RAM.
However, the real problem is that BASIC doesn't support the expansion memory.
Unfortunately I never really understood why someone couldn't make the second screen reside between &5000 & &8FFF or even &6000 & &9FFF for that matter! :(
Quote from: CP/M User on 09:35, 14 August 10
Unfortunately I never really understood why someone couldn't make the second screen reside between &5000 & &8FFF or even &6000 & &9FFF for that matter! :(
Unfortunately the hardware just doesn't work like that. And if it did, hardware scrolling wouldn't be available. Swings and roundabouts.
Quote from: TFM/FS on 18:06, 13 August 10
Well, it uses two 16 KB blocks or RAM: The usual screen (&C000-&FFFF) and the block between &4000 and &7FFF. It can't use the 0-3FFF block, because it contains the restarts. And it can't use &8000-&BFFF, because it contains part of the CPC-OS. And since the CRTC can access only the first 64 KB, you can't use the expansion RAM as second screen RAM.
However, the real problem is that BASIC doesn't support the expansion memory.
It doesn't, but I wonder if it could be easily tricked into it. If you modified that program to page one of the extra 128K banks into &4000 normally, but swap it back temporarily when the screen needed updating it should be possible to run on a 128K machine without losing usable memory and without actually modifying BASIC at all. Not that it wouldn't be nice if there was a BASIC which could use all available memory.
Quote from: andycadley on 09:53, 14 August 10
It doesn't, but I wonder if it could be easily tricked into it. If you modified that program to page one of the extra 128K banks into &4000 normally, but swap it back temporarily when the screen needed updating it should be possible to run on a 128K machine without losing usable memory and without actually modifying BASIC at all. Not that it wouldn't be nice if there was a BASIC which could use all available memory.
Absolutely right, it would be needed to patch a bunch of OS routine (print, draw, cls, etc...), but there it no reasan why it shouldn't work that way.