letzter Beitrag von Tale-X am
I need to access character ROM directly to get character bits for printing it to circle.
I used basic address 53248 and don't want to turn off Kernal & Basic - is other way?
Yes, it is possible to bank in the Char ROM while keeping Kernal and Basic. Look up the possible values for address $01 in the wiki.
But you need to disable interrupts before, because the kernal's handler code assumes I/O is banked in.
If performance is not important, you can draw the text in graphics mode using char. Then you can read and process the bitmap representation of the text... or store it with one of the shape-commands in a string for later use.
I doubt there is a "one routine fits all cbm" solution... I'm curious to see the final version of your program, which supports plain C64 and +4/C128. Keep us updated 
Something that works in Basic 7.0 ad Basic 2.0 at the same time would invole an ugly hack that I could think of:
1) print the character on screen at top left position
2) generate a sprite with one pixel only
3) move sprite to a position where it covers the leftmost pixel in top row
4) check sprite-character collision bit to see if it's set/reset
5) repeat 3+4 a total of 64 times for all pixels of the character
I guess such an approach is one of the more complicated "shoot yourself in the foot"-solutions
Jens
Use gcc and conditional compilation! (#ifdef)
I guess there's implementation pitfalls, as the collision bit is only updated once a VBlank, but Basic is faster than that (even though it feels darn slow). You may have to poll the bit maybe 10 times in order to be sure that it's really 0.
To be honest, I'm neither in the mood, nor would I have time to try it. If I had the time, I'd be in Hengelo, NL right now
Jens
Well, I was too curious to let this chance pass... You might wonder why I read the collision information twice - it's quite simple, reading twice brought a more reliable result. I'm not so happy with line 210 - a proper wait statement for checking the v-sync-event would be more efficient (I leave it as an exercise for the passionate reader 
)
3. now is only C64 computer which has chargen not accessible by simple Basic
This slowly BASIC routine copies the char set ROM into the RAM (12288 - 16383) for manipulating.
You might wonder why I read the collision information twice - it's quite simple, reading twice brought a more reliable result. I'm not so happy with line 210 - a proper wait statement for checking the v-sync-event would be more efficient (I leave it as an exercise for the passionate reader )
IMHO, it would have to be two wait-statements, as you need to make sure that the raster beam has passed once (Nyquist!).
Idea for improvement: If you switch on bitmap mode and show bitmap#0 of bank#0 or bank#2, you will see the whole charset without the need to print something on screen. Granted, not the entire charset, as the last 192 bytes are not shown, but since we know that the second half is just the inverted first half, that can be worked around. That saves you the "print character on screen" part.
This should also work on the C128.
All theory, though. I'm on Amiga stuff right now...
Jens
Setting sprite positions via POKE 53248 + x does not work in C128 mode, because Basic 7 (MOVSPR) uses pseudo registers at $11d6. The contents are copied to the VIC by the system interrupt (synced to vblank 
), overwriting the user's changes.
This feature can be disabled via POKE, but that POKE would be C128-specific as well, so just forget about using the same program on all machines. Detect the machine type and go from there.
and it works not...
Yes, it does.
So try it and you'll see.
Tried it, saw it. It works.
It draws mismatch, no text.
The code you posted doesn't draw anything, it just reads bits from the charset. And it does that correctly.
For compare test it on +4 or its emulator - diskimage with Basic 3.5 for C64 is attached.
Remove the POKE1,xyz stuff and you will see what the problem is: it looks as if Basic3.5 for the C64 changes the memory layout itself while doing PEEK(), therefore the program tries to read the charset info from i/o space.
Besides it's the kind of hack I love... 
