CPC Firmware hovercards

[Gryzor]

Hello everyone!

I don’t know if this is something genuinely useful, but it was a fun little project for me to do.

I just enabled an in-post firmware reference tool across the forum. When you post some machine code or hardware routines, hovering your cursor over a firmware vector, kernel restart, CRTC register etc will now pop up a card showing its inputs, outputs, corrupted registers, and a short summary of what it does.

It works in regular text, inline code, and syntax blocks.

To do this, I converted the Firmware Guide from Bob Taylor and Thomas Defoe into json format :
cpc-glossary.json (112.5 KB) and then the forum renderer picks the values if it recognizes an entry (from a list of 311) in a post you’re writing.

Hover your cursor over the vectors in these snippets to see it in action:

inline code:

; Wait for frame flyback to avoid screen snow
call &BD19 ; MC WAIT FLYBACK

; Set border ink to bright white
ld b, 26
ld c, b
call &BC38 ; SCR SET BORDER
ret

preformatted blocks:

; Switch to 320x200 4-colour mode
ld a, 1
call &BC0E       ; SCR SET MODE

; Print ASCII character
ld a, 65         ; 'A'
call &BB5A       ; TXT OUTPUT
ret

; Query attached joystick directions and fire buttons
call &BB24       ; KM GET JOYSTICK
; H = Joystick 0, L = Joystick 1

Any feedback will be more than welcome - feel free to diss it altogether, too!

[robcfg]

Oh, this is a nice feature!

Let me try…

CALL &BB18

CALL &BB18

CALL &BB18

Some remembers CALL &BA0A ? The one that added vertical bars to the whole display? Was that an unintended effect of jumping in the middle of a routine?

Edit: Colour me impressed that it works even when quoted or inside a code block!

[Gryzor]

@robcfg

Colour me impressed that it works even when quoted or inside a code block

That took a little while to fix, but I’m happy with how it works (initial version only worked outside code blocks because code blocks is where syntax highlighting works, too).

I thought about doing the same for BASIC as well but it would clash with natural language.

[ervin]

This is VERY cool!

Much better than having to go and look up what each jump block does.

[Gryzor]

Ah, that’s really good to hear. Not being a dev myself, I had no idea if this was going to be useful or just a nice gimmick - as I said, it was just something fun to work on with the forum capabilities

If you’ve got any ideas on how to make it better, let me know!

[Devlin]

Oh, that’s amazing. I love it. Great idea!

[robcfg]

Maybe if inside code blocks?

[Gryzor]

Already does, unless we mean different things?

[Devlin]

10 PRINT "HELLO"
20 GOTO 10

BASIC keywords get hints in code blocks, I think is what is meant?

[Gryzor]

Ohhh you meant for BASIC, ok. Yeah, that could be done.

My first hurdle is, what’s the input material? It was pretty easy to convert the firmware guide into a structured document as you can see in the OP, but what do we use for input with regards to BASIC?

Edit: even code blocks would cause problems, because even assembly blocks tend to contain natural language words that happen to be BASIC keywords.

This could be solved by using the custom entity when people want to add BASIC listings, like:

10 MODE 1: CALL &BC0E
20 SOUND 1, 478, 50

(note that this is a BASIC code block).

However, it would require people to make sure that the code is marked correctly as BASIC.

I did the BASIC code blocks when I did the automatic syntax highlighting and, in theory, it’s automatic, but it’s not well-tested -certainly, not by me.

[Gryzor]

@Devlin

BASIC keywords get hints in code blocks, I think is what is meant?

Done!

BASIC Hovercards

Soooo following the Firmware Hovercards and after @Devlin 's suggestion, I went ahead and implemented similar hovercards for BASIC keywords! Due to their similarity to natural language I had to limit them to code blocks only: 10 MODE 1: BORDER 0: CLS 20 INK 0, 0: INK 1, 26: INK 2, 6 30 ENV 1, 5, 1, 5: SOUND 1, 239, 50, 12, 1 40 ORIGIN 320, 200: DEG 50 FOR a = 0 TO 345 STEP 15 60 CALL &BD19: REM Sync to vertical flyback 70 DRAWR 100 * COS(a), 80 * SIN(a), 1 80 MOVER -100 * COS(a), -80 * SIN(a) 90 NEXT a 100 LOCATE 1, 24: PRINT "Press any key to reset palette..."; 110 CALL &BB18: REM Wait for keypress 120 CALL &BC02: REM Reset inks to defaults Ta-daaaah! In order for this to work, th…

[Jonathan]

It would be good if you do the same on the wiki itself. There’s at least one extension that you could get inspiration from - Extension:Lingo - MediaWiki.

[Gryzor]

I was actually thinking about that myself because the underlying mechanism is very similar to the point of re-using code. But is there enough code on the wiki to warrant it?

[cpcitor]

@robcfg

Some remembers CALL &BA0A ? The one that added vertical bars to the whole display? Was that an unintended effect of jumping in the middle of a routine?

From a quick check, it tells low-level firmware (“machine pack” then gate array) to switch to mode 2 without telling the high-level firmware (“screen pack”).

It’s a hack indeed. It jumps in the middle of code as you say.

Another option, clean in assembly and slightly hackish from BASIC, is to call MC SET MODE which does exactly this (low level call to set gate array, ignoring higher level firmware). Compare with SCR SET MODE which sets firmware mode and gate array mode and corresponds to BASIC MODE instruction.

This routine expects the machine mode in register A. BASIC CALL sets in A the number of arguments. You see where this is going:

mode 1
call &bd1c,0,0 'MC SET MODE with two parameters, -> mode 2

Setting a higher gate array mode than the firmware mode can split characters into bars, if they’re in PEN 1 or PEN 2.

Setting a lower gate array mode than the firmware mode can be useful to do poor man’s multicolor sprites or tileset in BASIC. Set mode 2 in firmware with paper 0 : pen 1, with gate array in mode 1 (or even 0). Use SYMBOL to define characters with patterns intended for the gate array. Firmware draws these patterns thinking they’re monochrome, gate array draws the colors you mean.
One characters occupies a mode 2 char width, so 4 pixels in mode 1, 2 pixels in mode 0, and always height 8.
Tileset and/or sprites without a single line of assembly.