Tuesday 4 November 2014

More work on proportional fonts

I am edging my way towards getting hardware proportional fonts working.

To recap progress to date, text mode can be switched to 16-bit mode, where two screen RAM bytes and two colour RAM bytes describe each character instead of one of each.  Some of those extra bits can be used to specify the width of a character, between 1 and 8 pixels wide.  Thus proportional fonts can be constructed using some full-width characters and some narrowed characters.

I have now written a little programme that takes a true-type font, and produces a font file composed of 8x8 character blocks.  It isn't perfect, but it does create a simple file with a list of unicode points, tile maps that say which tiles go to make each glyph, and then the array of 8x8 tiles, 64 bytes each.  You can see the source at:

http://github.com/gardners/c65gs-font-rasteriser

It doesn't do any compression of the 64-byte blocks, so the fonts are quite a bit bigger than they need to be.  However, it should be very easy to write some 6502 assembler that given a 16-bit unicode string, can setup a 16-bit text mode screen to display the text.

Simultaneously, I have been working on the anti-alias renderer for 8x8 tiles. It isn't done yet, but the alpha blender is in the design now.  Assuming that it works, it shouldn't be too hard to plumb it in, and start displaying alpha-blended 8x8 character tiles.

10 comments:

  1. OMG :) Your project is really interesting and hmm complex :) Do you have any "table of contents" like document? I mean, it's just too hard to collect information by always digging in every posts from you to try to form the "big picture" in my brain. Thinks like a TOC, documents about the current features, registers etc can be useful. Sorry I don't want to disturb you in your work (because it's really interesting), just I am wonder, if you have those, or want to do those, etc. A bit another topic: since I've started to write an OS for Commodore 64 DTV (using its great abilities like 256 colour mode, blitter, DMA ...) I wonder if I can code later for C65GS as well maybe! However for example I am not sure how memory is banked, the regular "C65" way, or is there some kind of extra? Since personally I think, memory banking of C65 is quite hmm "odd" compared to the nice solution DTV (and also some other even not Commodore machines) has, ie: CPU sees 64K, divided into four 16K long segments. The main memory is also segmented like this way. You can simply tell that in any of the CPU's "windows" you can see any of the memory segments. So simple, but somehow Commodore always made the banking quite limited or even overcomplicated. In my opinion only, I mean :) Of course the ideal solution would be something like 65816 without any segments which eg would solve the "IRQ got while we are paged out the memory from there" and similar problems. Ok, I am just thinking here.

    ReplyDelete
    Replies
    1. Hello,
      You are quite right about the lack of documentation at the moment. Apart from the VHDL source code, which I concede is a bit opaque for most, someone has just started working on exactly this. Join the C65GS developers Google group, and you will be able to get the current version, and point out areas that lack documentation. Hopefully we can make the generation of the documentation collaborative. I'll respond to memory mapping etc in a moment.

      Delete
    2. Sounds nice re DTV OS. You are certainly welcome to work on something similar for the C65GS. Memory is banked mostly the C65 way, which means that you can select whether each 8KB block is banked, and separately choose the offset for banking for the lower and upper 32KB halves. I agree that this is a rather odd arrangement that Commodore came up with, but it works fairly well, especially since you have a 48MHz DMA controller to pull memory in from elsewhere when needed. There is probably some scope to add some other banking magic, but I want to keep it to a minimum. The only addition to the C65 banking regime that I have made is to add an extra 8 bits of address to the top, taking the address space from 1MB to 256MB. This is also controlled with the MAP instruction using some special values. One advantage to 8KB windows is that it is easier to keep your IRQ routine always mapped, without compromising too badly.

      Keep the thoughts coming!

      Delete
    3. That's exactly what bothers me: the mapped not mapped, it does not make any sense in my opinion: etc mapping something (in a more "sane" banking method) from 0 is exactly the same as "not mapped", I never understand why it is needed to make difference (it is also a part of my opinion that banking/paging on Commodore machines are overcomplicated, a much more simple way is not provided like what I've described for the C64DTV as an example). About the IRQ: what I like about 65816 that it can serve IRQ (and other interrupts) even if the vector is not seen by the CPU currently. Ok, 65816 is different theory. Thus some kind of "IRQ mapping" would be great: to use a certain mapping automatically if IRQ comes, even if it's not mapped currently. This is great that you can use all of the CPU 64K address space and no need for worrying about IRQ (or RESET, or BRK for eg "syscall" like instruction in an advanced OS). Of course then, there should be a way to backup/restore mapping automatically ........

      Delete
    4. Yes, I agree that mapping to 0 is a bit strange, but that's what we have to work with. As for IRQs etc triggering outside of the current 64KB, while the C65 doesn't do that, I have already added a simple hypervisor facility to the C65GS that saves all CPU state -- including memory map -- and sets up a specific memory map and jumps to a vector there. This also has the advantage that entry and exit take one cycle, even though about 20 bytes of information gets saved.
      Paul.

      Delete
    5. By the way, something similar is implemented with the almost unknown Commodore LCD (I dunno about C128, even if Bil Herd told me that C128's MMU is a thing created after the LCD's learning lessons from it) machine: though it has fixed mapping for the top area of the memory, it can save the MMU mode and restore the saved one. Of course it's still not "perfect" as it forces you to have the top of the memory always mapped in, which would be nice not to be compulsory :)

      Delete
    6. Ah sorry, too much comments :) About about the VHDL: though I have a dream to start FPGA etc projects, I failed all the times when I tried to learn Verilog and/or VHDL somehow it's just alien for me regardless my willpower to learn it. I can code in many languages (including assembly for multiple CPUs, and higher level languages too), HDLs are so different as you know it too :) Also notions like RTL level etc, just confuses me, I just want to describe the logic and that's all, I don't want to deal with these complex topics, but it seems it is not the way it works :( But you, as an experienced person in this topic may be able to suggest some good resources for a guy like me (ie who has not so much knowledge on the topic, and don't want to dig in the deep field just create projects as simple as possible and of course to learn some HDL let it be Verilog or VHDL) to learn ... But this should be sent in a mail or such not as a comment on a totally different topic, I guess :) Sorry about that.

      Delete
    7. If I had to describe the mental shift from assembly language to VHDL, it is simply this: 1. Everything happens at once. 2. Your job is to calculate the signals to tell everything what it is doing (or not doing) during the next cycle. Basically apply your understanding of how a CPU works, and make your own functional units and the control logic to tell them when to do stuff. As for particular material to learn, I think just google for tutorials or start looking at simple projects. Start with the blinking led type things, and then work your way up. If you can make a simple state machine in VHDL, you have learned the single most important skill.

      Paul.

      Delete
  2. Paul, I am very concerned about the rationality of implementing the proportional font functionality like this. I have sent you an e-mail because the post was apparently too long for me to send it here. If at all possible, could you please discuss on the group board?

    Thanks.

    ReplyDelete
    Replies
    1. Hi Daniel, I haven't seen the message yet, but will look for it. Certainly happy to discuss it on the list.

      Delete