| Posted By
Dunric
on 2004-04-23
05:24:02
|  Another Plus/4 question...
The example posted earlier works well. In the custom character example previously posted, BASIC is dropped down to 53247. Custom characters begin to be loaded at 53248 through 55295.
However, this also means that I lose 11.5KB, when I really only need to alot 2,047 bytes for an upper and lower case character set (I am redefining 90 or so characters).
The characters redefined are:
@ABCDEFGHIJKLMNOPQRSTUVWXYZ
01234567890,.<>?/;:[]"+-'!@#$%^&*()
abcdefghijklmnopqrstuvwxyz
In the example program, I simply use:
FOR I=0 TO 512
READ B : POKE 53248+I,B
NEXT
FOR I=0 TO 231
READ B : POKE 54744+I,B
NEXT
I also use thed the POKE 55,255 : POKE 56,207:CLR suggested earlier.
However, would POKE 55,255 : POKE 56,228:CLR be easier? This leaves 6.1KB for
custom characters, dropping BASIC down to 58623 (if my calculations are correct).
Would I then start loading custom characters beginning at 58624?
How about PEEKING the ROM to RAM, a la:
FOR I=58624 TO 60671 : POKE I,PEEK(I):NEXT
In the previous example, the following was used:
FOR I=53248 TO 55295 : POKE I,PEEK(I):NEXT
To display the custom character set, they suggested:
POKE 65298,PEEK(65298) AND 251
To switch it back:
POKE 65298,PEEK(65298) OR 4
Sincerely,
Paul
|
|
Posted By
JamesC
on 2004-04-23
07:51:02
| Re: Another Plus/4 question...
Paul,
TED requires that the character set be on a 2k boundary. I calculate the highest spot to be $F000; anything higher will conflict with the modem and DMA ports.
If you're going to MOVE the character set, you also need to tell TED the new location by POKEing the high byte to 65299. Be careful when doing this, as the lowest two bits are used for other purposes and should not be messed with. Only the upper 6 bits hold the character base.
My suggestion for putting the RAM-based characters at 53248 was for simplicity. As someone in comp.sys.cbm pointed out, you could simply use a GRAPHIC1:GRAPHIC0 to reserve RAM and put your character set in that 12k block.
|
|
Posted By
Dunric
on 2004-04-23
16:05:41
| Re: Another Plus/4 question...
Someone suggested lowering BASIC to 61439:
POKE 55,255 : POKE 56,239 : CLR
However, the screen is all messed up when I attempt to POKE my character set
starting at 61440.
Is the POKE to 65299 the following:
POKE 65299,(PEEK(65299)AND3)OR(60)
Paul
|
|
Posted By
JamesC
on 2004-04-23
16:32:40
| Re: Another Plus/4 question...
Paul,
Lowering BASIC to 61439, and putting the charset at 61440, are the same idea, simply worded differently.
1) POKE55,255 : POKE56,239 : CLR : REM LOWER TOP OF BASIC
2) POKE1177,63 : REM ALTER BASIC PEEK
3) Copy charset to 61440
4) POKE1177,62 : REM RESTORE BASIC PEEK
5) POKE 65298,PEEK(65298) AND 251 : REM TELL TED TO GET CHARS FROM RAM
6) Initialize TED to see your charset at 61440 with POKE 65299,240 (this will set the lower two bits to zero, those bits have to do with a timer that I doubt you'll be running at the time you do this)
You will have a glitch for a moment but then your screen will be fine. I myself would clear the screen before copying the charset, that way there is nothing on the screen to go weird when TED is looking at the wrong data for a split second.
|
|
Posted By
Dunric
on 2004-04-23
17:28:28
| Re: Another Plus/4 question...
Awesome, thanks! 
|
|
Posted By
Csabo
on 2004-04-23
17:59:58
| Re: Another Plus/4 question...
Glad to see that the problem is worked out. Just a few technical comments regarding to what James C said: even though the font has to be on a 2K boundary, you can use "half" of a font if you set $FF13 to a 1K boundary. (e.g. something like POKE DEC("FF13"), DEC("3C") - in fact there a few commercial C16 games that use only half a set to push the code all the way up to $3BFF and the rest is the font). This is essentially the same as the C= + Shift switch, which can be disabled.
As long as you can use 128 chars + reverse, you can safely use $F800 for font. If you can manage from only 32 chars (that's pretty much uppercase letters and punctuation, might be enough for a text adventure), you can use $FC00. It won't interfere with anything in the upper memory area, as long as you leave it alone.
|
|
Posted By
Dunric
on 2004-04-23
18:52:05
| Re: Another Plus/4 question...
Csabo,
I'm modifying Wizard Castle at this moment between a C-128D and a Plus/4 running simultaneously.
I fix the bugs in C-128 mode, scratch it, save it, then I load it up in the Plus/4 mode to test out the new fonts. Once they are satisfactory (and run without causing an ?OUT OF MEMORY ERROR) then it will also make the font available for the C64 and 128 mode version of the game.
Paul
|
|
Posted By
JamesC
on 2004-04-23
23:32:18
| Re: Another Plus/4 question...
Paul,
The C64, Plus/4, and 128 all define the "base" character fonts in the same way. If you are hurting for program space, define the fonts and then save them to disk.... the reload them to the proper area depending on what machine you're running on. (You might have a font.c64, font.+4, and font.128 just to simplfy load addresses. They'll be the same font, just saved three times on disk. But see below about reverse characters.)
What Csabo suggested about using "half" a font: that works fine on C16 because copying the remainder just dumps it into never-never-land. However on the Plus/4 if you start tinkering with the ACIA or the DMA ports you have problems waiting to pop up. I would recommend sticking with what is working, as far as the font is concerned.
And what I have suggested to this point has not included reverse characters....... TED generates reverse characters on its own in the Plus/4, but if you absolutely need to define reverse characters differently then TED can be told to read the reverse characters from RAM instead. In which case we may have to move the charset, I do not have my handy-dandy book of all knowledge in front of me to check.
|
|
Posted By
Csabo
on 2004-04-24
08:57:57
| Re: Another Plus/4 question...
You do NOT have to tinker with ACIA or DMA port or anything to use a charset from $F800. You just have to leave the other half of the font (above $FC00) alone.
You said that it would work on a C16 because the rest goes to never-never-land. This is incorrect! I can see that you are assuming that still the WHOLE set would be copied. However, on the C16, $4000 is mapped to $0000, etc, so it would not go to never-land, but rather to $0000 and therefore lock up the machine.
Bottom line, if you are using half a font + reverse, it is enough to copy the ROM font from $D000-$D3FF.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
