[IntyBASIC] - A more colourful font

[carlsson]

Yeah, before we know it someone has found the set of instructions required to turn the built-in font into Courier and Comic Sans!

I'm not sure if either of these would be practically useful, but here are two more:

Speed/Striped

  asm repeat 4
  asm mvi@ r4, r0
  asm mvo@ r0, r5
  asm mvi@ r4, r0
  asm movr r0, r2
  asm sll r0,1
  asm andr r2, r0
  asm mvo@ r0, r5
  asm endr

Shaky/Spooky

  asm repeat 4
  asm mvi@ r4, r0
  asm movr r0, r2
  asm slr r0,1
  asm andr r2, r0
  asm mvo@ r0, r5
  asm mvi@ r4, r0
  asm movr r0, r2
  asm sll r0,1
  asm andr r2, r0
  asm mvo@ r0, r5
  asm endr

Edited February 17, 2016 by carlsson

[GroovyBee]

I'll add those into the next release too.

[+nanochess]

It looks like we are good for fonts

[freewheel]

Anyone able to give a quick summary of what all this font modification is? I see a lot of ASM being bandied about. What are the tricks involved here?

[carlsson]

To summarize, the original idea was to copy (parts of) the GROM font to GRAM, in order to use more foreground colours. In order to do so, GroovyBee created an assembly language routine that would be inlined with IntyBASIC and called. As demonstrated, it would be possible to accomplish with POKE from BASIC too, just that you need to add wait statements and it takes more time to execute.

 

Then I got curious and inserted one or two additional instructions into the assembly language code to obtain variations, and from there stemmed a series of other variations. As noted, you could define your own font with bitmaps and load it in the regular way, but this way might save a little on program size at the cost of how varied you can make the font. The "data" style font was a nice surprise, I had not realized it could be obtained so easily.

[GroovyBee]

The font creation code was getting out of hand so its been compacted. I've also added the digital font from nanochess and carlsson's speedy and spooky fonts. The font string printing function has been modified so support digits 0 to 9 and some limited punctuation consisting of ".", ",", "?", "!" which should make it a bit more useful. Anything the font string printer doesn't understand is replaced wuth a "?".

 

Latest screenshots :-

 

Latest code :-

Grom2GramFont.bas

 

Latest ROM :-

Grom2GramFont.rom

[Kiwi]

I really love procedural programming. I'm really impressed by the number of variation that is produced by using the original font.

[carlsson]

I don't want to be a Messerschmidt, but it is February 2016 by now and this thread hasn't been going on that long.

[GroovyBee]

I really love procedural programming. I'm really impressed by the number of variation that is produced by using the original font.

 

True! Its also good to see several people expanding the original idea so that IntyBASIC users get 9 fonts available in all 16 colours.

[GroovyBee]

I don't want to be a Messerschmidt, but it is February 2016 by now and this thread hasn't been going on that long.

 

I know

[Kiwi]

 

 

With some unrolling you can do more work per loop (not tested) :-

    #src=$3000
    #dest=$3800
    for #c=0 to (64* step 8
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
        poke(#dest,peek(#src))
        #dest=#dest+1: #src=#src+1
    next #c

With rolled up loop. I added if d=14 then wait:d=0 to test my theory having that there to see how much it can copy from GROM to GRAM before being denied write access.

mode 0,15
include "constants.bas"
for c=0 to 239
    #BACKTAB(c)=GRAM+CS_LIGHTBLUE+(c*
    next c
	d=0
	wait
	for #pointer=0 to ((64*-1)
		if d=14 then wait:d=0
		#junk=peek($3000+#pointer)
		poke($3800+#pointer,#junk)
		d=d+1
	next #pointer
loop:
goto loop

I tried using higher number than 14. 14 is the most it can draw a frame during the vertical blanking before the STIC start drawing the screen. Higher than 15 will result blank line to appear in your font.

[GroovyBee]

For a pure IntyBASIC syntax version, loop unrolling is the way to go. For comparison, the assembly language version (its unrolled per character) does 13 complete cards per wait command.

[Kiwi]

I had a thought when I left for work right after work. Is there a signal or flag when the vsync2 begins when it just finished drawing the screen element and start drawing the bottom border to tell the processor that the memory is now writable? I could probably get it to draw more during Vsync2 before interrupt occurs. Just wondering.

[GroovyBee]

I had a thought when I left for work right after work. Is there a signal or flag when the vsync2 begins when it just finished drawing the screen element and start drawing the bottom border to tell the processor that the memory is now writable? I could probably get it to draw more during Vsync2 before interrupt occurs. Just wondering.

 

No such flag exists as far as I'm aware. If you read interrupts.txt in the SDK1600 it explains the interrupt process. Basically GROM and GRAM are available for more cycles after the interrupt than the STIC registers are. The only way to program more cards would be to disable the display or hook a new VBLANK IRQ handler that does less "work" than the default one.

[+DZ-Jay]

 

No such flag exists as far as I'm aware. If you read interrupts.txt in the SDK1600 it explains the interrupt process. Basically GROM and GRAM are available for more cycles after the interrupt than the STIC registers are. The only way to program more cards would be to disable the display or hook a new VBLANK IRQ handler that does less "work" than the default one.

 

That is correct. There is only one interrupt signal captured by the CPU (and exposed by the EXEC), the Vertical Retrace or Vertical Blanking (VBLANK) interrupt. This period has two phases, which have been documented by Joe Z. and others as "VBLANK 1" and "VBLANK 2." The first one is a shorter period in which the STIC registers are available to your program, while the second persists for several hundreds of cycles more, and allows you to access GRAM.

 

Note that GRAM is available during both phases, so you can think of it as the longer "regular VBLANK" (for GRAM) of which only a short period at the start gives you access to the STIC.

 

This enforces certain structure to underlying kernels, including IntyBASIC's own. The typical low-level approach of many programs is, of course, to update the STIC at the very top of the VBLANK Interrupt Service Routine (ISR), followed by any GRAM updates necessary.

 

Unfortunately, there is no signal to tell when VBLANK ends, but it's timing is precise (due to its synchronisation with the TV signal), so what we do in Assembly Language programs is count the cycles of our game engine to make sure they fit within allotted window. This is much harder to do in IntyBASIC.

 

That said, there is a nifty trick you can use: the debugger provides verbose information on "dropped" reads or writes to the STIC or GRAM. If you enable this feature, you can tell if your program is trying to access either for longer than it should. It will also point to the specific source line (in the assembly listing) where it occurred, as well as the specific CPU step (from the CPU history dump/log).

 

Here are the relevant debugger commands:

STIC Specific
   ^           Toggle displaying dropped writes to STIC registers or GRAM
   %           Toggle displaying dropped reads of STIC registers or GRAM

Statistics / History tracking:
   h           Toggle history logging.  Use "d" to dump to "dump.hst"
               and "dump.cpu"
   d           Dump CPU and memory state to a series of files.  Requires
               history or attribute logging to be enabled.

For more information on interrupts, their timing and duration, you can consult the IntelliWiki site.

 

One last thing on the topic. Like GroovyBee said (and I have stated before), access to the STIC and GRAM during VBLANK is only curtailed by the need of the STIC to assert the video bus in order to draw the next frame. This means that if it were relieved of this responsibility, you could have unfettered access to the video resources.

 

You may find it strange to learn that the default operating mode of the STIC is to not draw the next frame and disable the video display. Your program has to actively tell the STIC to draw the frame by expressly writing into the STIC's "enable display" register (any value will do, it's the act of writing on the register that triggers the mode). It is therefore common for programs to do just that as the very first thing in their ISR. In fact, this is what IntyBASIC does.

 

Another common technique (one which I use myself often) is to use a different ISR during initialisation, where the display is kept disabled, and thus your program can access GRAM and the STIC all it wants, while the screen remains blank for a few frames. Unfortunately, IntyBASIC does not currently support this, having a single ISR during program execution (its kernel), where the display is always enabled by default. This forces your program to "wait" for the next VBLANK interrupt in order to continue loading video data.

 

Perhaps nanochess will consider supporting a mechanism for users to disable the display temporarily. This could be useful for graphics-heavy level or game initialisation sequences.

 

-dZ.

Edited February 19, 2016 by DZ-Jay

[carlsson]

Great, that answered one of my other questions that I so far haven't dared to ask, namely if the STIC can be addressed multiple times during one frame for e.g. partial horizontal scrolling. Apparently the answer is no.

[GroovyBee]

This is the final version (I hope). The font printer is now more closely coupled with IntyBASIC's screen positioning code, such that a print "" after a call PRINTFONT will add the text to the end of the last string. I've also added an inverse font and a test in foreground/background mode that uses the inverse font to display text in any of the 16 background colours.

 

New screenshots :-

 

Source code :-

Grom2GramFont.bas

 

ROM :-

Grom2GramFont.rom

[+5-11under]

This is the final version

 

LOL

[+DZ-Jay]

Great, that answered one of my other questions that I so far haven't dared to ask, namely if the STIC can be addressed multiple times during one frame for e.g. partial horizontal scrolling. Apparently the answer is no.

 

What do you mean, "addressed multiple time during one frame"? It can be addressed as many times as you'd like, as long as you do so within the "VBLANK 1" period. Notice that this period is rather short.

 

To give you an idea of how short, consider this: In my game, I keep a copy of of STIC in RAM in order to make changes outside the critical path, and I post it to the STIC during VBLANK. This "Shadow STIC" was 24 16-bit words long, which covered three registers (X, Y, Attribute; ignoring the Collision register) for each of the eight MOBs.

 

I learned that if I do this copy in a loop (with a counter, test, and branch), it wouldn't have enough time to complete it in time, and the last few writes would be dropped. Consequently, I had to unroll the loop and just put every copy instruction inline (with no test and branch) for it to fit in time. It is that tight.

 

-dZ.

[+DZ-Jay]

Great, that answered one of my other questions that I so far haven't dared to ask, namely if the STIC can be addressed multiple times during one frame for e.g. partial horizontal scrolling. Apparently the answer is no.

 

 

 

What do you mean, "addressed multiple time during one frame"? It can be addressed as many times as you'd like, as long as you do so within the "VBLANK 1" period. Notice that this period is rather short.

 

 

Oh, I think I understand what you mean: if you can intercept the STIC during horizontal retrace. Unfortunately, as you surmised, the answer is no. You can do that in the Atari VCS and some other consoles (this was popular for multiplexing sprites on the C=64, or for doing split screens), but the Intellivision does not work that way.

 

The Intellivision does not expose any other facet of the TV control mechanism other than the vertical retrace interrupt. That means that by the time we get the interrupt and access to the STIC, the last frame has been completely composited and buffered.

 

I will add that we should all be thankful that we even have that! The designers of the Intellivision could have been more conservative in their vision and hard-wired the interrupt vector to the EXEC's ISR in ROM. The fact that they stored the vector in RAM, and that we can change it at will, is what allows independent home-brews to exist and bypass the EXEC completely.

 

-dZ.

[+DZ-Jay]

By the way, I'm very impressed by the procedural fonts, especially the "Thin" and "Digital" ones. Great job, guys!

 

-dZ.

[GroovyBee]

With a slight modification to the font preparation code it could copy the lower case letters into GRAM. That'd be useful for foreground/background mode. But I'll leave that as an exercise to the reader .

[First Spear]

What would it take to make a vertical font with vertical PRINT?

 

I updated a song this morning, merged it into the visual player by @mmarrero, and now see that there is some "open screen real esatate" on the right side of the screen... It would be cool if I could just PRINT the title of the song in that area while the music is playing.

 

See http://atariage.com/forums/topic/254462-intybasic-rough-song-1812-overture/?p=3567854to understand what I am talking about.

 

Thanks!

 

 

 

I thought this would be more useful in a thread on its own. The example shows how to copy the upper case letter cards "A" to "Z" and digits "0" to "9" from the font in GROM into GRAM and then make use of them.

 

Screenshot :-

Gram2GromFont.gif

 

Source code :-

Gram2GromFont.bas

 

Any problems or questions let me know.

[GroovyBee]

Its certainly possible to have a vertical font printing routine but you would lose the "on the fly changes" that are applied to the standard font as its pulled from GROM.

[First Spear]

 

It might make IntyBASIC more "BASIC"-y to have vertical printing. I don't need it that bad personally, just another wild thought.

 

Its certainly possible to have a vertical font printing routine but you would lose the "on the fly changes" that are applied to the standard font as its pulled from GROM.