Char_Use issue in Mode 8 - JS ROM

[Andrew]

Is the Pointer Interface loaded in any of these cases? That shifts the variables in the channel definition block and might possibly confuse non-aware Toolkit versions.

It's the same behaviour with or without PE

[Martin_Head]

What if you try using the second font area.

Also if you can find the start address of the channel definition block for the screen channel, You could peek the two long word addresses of the fonts,
$24 SD.FOUNT.

This would at least tell you if TKII is actually setting the new fount addresses in the channel definition block. Or if QDOS is somehow ignoring them.

[Andrew]

What if you try using the second font area.

Also if you can find the start address of the channel definition block for the screen channel, You could peek the two long word addresses of the fonts,
$24 SD.FOUNT.

This would at least tell you if TKII is actually setting the new fount addresses in the channel definition block. Or if QDOS is somehow ignoring them.

I used DYI toolkit extension chans_code to read the font addresses

JS ROM - the values are not changed in the definition block
Minerva, JM, MG, Spanish MG - the values are changed in the definition block and the font is used

Code: Select all

8  TK2_EXT
9  LRESPR mdv1_chans_code
10 CLS
15 PRINT 'ROM = ';VER$
20 PRINT "This is standard font"
25 ShowFontAddress
35 x=ALCHP(875):y=ALCHP(875)
45 LBYTES win1_digital1_fnt,x
55 LBYTES win1_elaborate_fnt,y
65 PRINT "Fonts will be loaded at addresses:"
75 PRINT "Font1 = ";HEX$(x,32);" : ";x
80 PRINT "Font2 = ";HEX$(y,32);" : ";y
90 PRINT "-------------------------------------------------"
95  CHAR_USE x,y
100 PRINT "This is the loaded font"
110 ShowFontAddress
120 PRINT "-------------------------------------------------"
130 CHAR_USE 0,0
140 PRINT "This is standard font again"
150 ShowFontAddress
1000 DEFine PROCedure ShowFontAddress
1010 Font1=CHAN_L(#1,42)
1020 PRINT "Font1 = ";HEX$(Font1,32);" : ";Font1
1030 Font2=CHAN_L(#1,46)
1040 PRINT "Font2 = ";HEX$(Font2,32);" : ";Font2
1050 END DEFine ShowFontAddress

[Martin_Head]

Just to be sure. What if you manually POKE the new font addresses into the channel definition block. Does the fonts change? or is something resetting them?

Can you write a small machine code program to set the fonts with the system trap SD.FOUNT to see if that works.

You said you are using a ROM switcher, Have you put actual JS ROM's in the QL and tried it. Maybe the JS ROM in your ROM switcher is bad?

[Andrew]

Just to be sure. What if you manually POKE the new font addresses into the channel definition block. Does the fonts change? or is something resetting them?

Can you write a small machine code program to set the fonts with the system trap SD.FOUNT to see if that works.

You said you are using a ROM switcher, Have you put actual JS ROM's in the QL and tried it. Maybe the JS ROM in your ROM switcher is bad?

1. POKE works for all ROMS, including JS
2. SD.FOUNT works for all ROMs, including JS
3. CHAR_USE is not working on JS ROM to set a font or to revert to standard fonts, but works on all other
4. I do not have a JS ROM I think that I have another ROM switcher stashed in some drawer, I'll look for it.

This is strange. I expect CHAR_USE to also use SD.FOUNT trap

[Martin_Head]

You could test the ROM by loading a Qemulator JS ROM into memory, then run a loop in BASIC to compare the loaded ROM image with the physical ROM.
That should work, so long as your not using anything like a gold card that replaces the ROM with RAM.

The only other thing I can think of at the moment, is to use a monitor program like QMON to trace the the CHAR_USE command.

You would have to find the start of the CHAR_USE routine. By searching the name list/table, unless you can find a toolkit that will find the address.
Then stick a breakpoint in there, and then trace through to see where things go wrong.

I'm not sure if this has already been suggested, or you have tried it. But do you get the same problem if you open a console channel then use CHAR_USE#ch,

I'm just wondering if there is something weird where CHAR_USE is picking up the wrong channel ID. Is there anything weird in the BOOT program that closes #1, then reopens it.

[Andrew]

I'm not sure if this has already been suggested, or you have tried it. But do you get the same problem if you open a console channel then use CHAR_USE#ch,

I'm just wondering if there is something weird where CHAR_USE is picking up the wrong channel ID. Is there anything weird in the BOOT program that closes #1, then reopens it.

Yes, I get the same error if I open a console channel or a screen channel.
I noticed the issue when I tested PITMAN on my JS bbQL - in Pitman code I open channels 3 ,4 and 5 for different windows. And I noticed 2 issues:
1. if PE is loaded than in the compiled program the print#x will not show until I do a inkey$(#x,1) if x is the program's first opened channel or a default channel (0, 1 or 2)
(Actually I already knew about this since I developed PI Cole)
2. CHAR_USE was not working for _con and _scr channels

[Martin_Head]

You could test the ROM by loading a Qemulator JS ROM into memory, then run a loop in BASIC to compare the loaded ROM image with the physical ROM.
That should work, so long as your not using anything like a gold card that replaces the ROM with RAM.

You could also try going the other way. Save your JS ROM and TKII to files and try them in Qemulator.

[Andrew]

You could test the ROM by loading a Qemulator JS ROM into memory, then run a loop in BASIC to compare the loaded ROM image with the physical ROM.
That should work, so long as your not using anything like a gold card that replaces the ROM with RAM.

You could also try going the other way. Save your JS ROM and TKII to files and try them in Qemulator.

Thank you Martin - now we are getting somewhere.
I saved the JS ROM from the switcher and and loaded in QEmulator - it works perfectly.
But the JS ROM has some differences compared to the JS ROM downloaded from Dilwyn's site. It seems that it ends with a piece of TK2 or something ...
Also at address 254H the switcher rom has D6C0 while the JS ROM has D7C0
Nevertheless, it works in QEmulator and CHAR_USE works properly.

I disabled the ROM TK223 and LRESPRed TK236 on the bbQL - and with it, CHAR_USE is working properly.

I do not know what it means. All ROMS from switcher use the same TK223 - and with all ROMS except JS, it works.

[Martin_Head]

But the JS ROM has some differences from the JS ROM downloaded from Dilwyn's site. It seems that it ends with a piece of TK2 or something ...
Also at address 254H the switcher rom has D6C0 while the JS ROM has D7C0
Nevertheless, it works in QEmulator and CHAR_USE works properly.

That looks like a single bit error in the EPROM/FLASH (whichever is in the ROM switcher).
A quick look at a JS disassembly on Dilwyn's site gives

Code: Select all

L0246   bsr.s   L0250                   ;set sv_jbpnt, sv_jbbas and sv_jbtop
        mulu.w  #3,d0                   ;maximum 360 channel table entries
        bsr.s   L0250                   ;set sv_chpnt, sv_chbas and sv_chtop
        bra.s   L025C

;Set table pointers

L0250   move.l  a3,(a4)+                ;current entry pointer
        move.l  a3,(a4)+                ;start of table pointer
        adda.w  d0,a3                   ;size of table
        move.l  a3,(a4)+                ;end of table pointer
        addq.w  #4,a4
        rts

So address 254H is something to do with setting up the job tables?

I disabled the ROM TK223 and LRESPRed TK236 on the bbQL - and with it, CHAR_USE is working properly.

I do not know what it means. All ROMS from switcher use the same TK223 - and with all ROMS except JS, it works.
ROM.jpg

I found this on Dilwyns site. Note the bold bit at the end.

JSTK223.zip (48K) - A 64K ROM image containing a JS ROM and a version 2.23 Toolkit 2 which is Level-2 filing system aware. Since the v2.23 is slightly more than 16KB in length, and the JS ROM set has sufficient spare unused space, it was possible to combine them into a single 64K image which could be burned into an EPROM which could be plugged into the correct addressing space in the QL ROM slot. A small BASIC program is supplied to enable this to be used on QemuLator also by splitting the 64K image into 48K system ROM and 16K toolkit. The version updated on 03/03/16 fixes a problem when QL ROM slot at $0C00 also being shadowed/recognised at unused address $CC000 (Like earlier TK2 versions, detects false call and returns). The version updated on 16/03/16 fixes an issue whereby the CHAR_USE command may not work. (David Westbury) [16/03/16]