Jump to content


Photo

Manic Miner Font


  • Please log in to reply
5 replies to this topic

#1 Spider

Spider

    DEC (HL)

  • Administrator
  • 2,906 posts

Posted 24 January 2018 - 10:10 PM

A question.

 

I took a glance at about a dozen builds of Manic Miner games but none of the ones I saw had a different font/character set for some reason.

 

Given that its possible to change this via a simple poke anyway and the fact there's a large chunk (2480 / #9B0 bytes) of 'usable space' at 37708 / #934C , this seems quite odd.

 

Note the above is the Bug-Byte version, the S.P and MAD/Venta still have the space but its not got source code remains in, it should be a bit higher up probably 33719 / #83B7 in these versions, but lets ignore those and stick with the B-B one otherwise this will get too confusing. The SP version contains a repeating pattern of 0 / #00 , 255 / #FF to 'fill' this space up.

 

I did try quite a few months ago to implement this change but despite my efforts at the time I could not get it to sit within a permitted boundary, given how the print routine works. The routine is identical in both JSW and MM so the 'fix' should be the same. The effects usually resulted in corrupted font output (printing graphics or nothing) or in some cases the wrong character by quite a way such as say printing "G" instead of "4" for a random example. I cannot recall exactly what was printed or not. I do recall trying then to manually just insert the font data a few bytes up or down to 'test' it (ignoring any potential crashes) but still got stuck.

 

In JSW to erm 'redirect' it elsewhere it is simply POKE 38546 / #9692 , x , this instruction is merely LD H , 7 so its the 7 that we would change.

 

In MM the same code resides at 37579 / #92CB and the instruction is the same LD H , 7 , so the change is POKE 37580 / #92CC , x to replace the 7 with another value.

 

There is the slight chance of putting the 'font code' elsewhere such as buried in the top third of the graphic data or the middle section however given how the screen memory (and memory in general) it would take a lot of work to 'hide' it there without destroying what was present. The huge gap would be great *if* it could be used, the fact its a shade over 2K in size does make me think this is possible.

 

Any thoughts ? :)


Changing order to chaos since 1984

#2 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 120 posts

Posted 25 January 2018 - 11:51 PM

Rough figures... 

 

 

                                          ;****************************************

                                                            ADDENDUM

                                           ****************************************

I originally used the terminology of REM'd out for the SET 7,L in the code.

This is only possible in an assembly listing and is not possible with situations such as this.

The nearest equivalent would be inserting NOP,NOP.

However this makes a slight change in how the text is handled.

The stream of text going through the print routine could have any value, and might be over 127

With that in mind, it would make a far better change to use RES 7,L as the alternative to SET 7,L

                                             *******************************************

.

 

.From listing of JET SET WILLY Numbers in HEX

.

9691 LD H,$07
9693 LD L,A
9694 SET 7,L          ;could delete   NOP'd   >>> use RES 7,L
9696 ADD HL,HL     ;*2
9697 ADD HL,HL     ;*4
9698 ADD HL,HL     ;*8
9699 LD B,$08

.

Changing the opcode at #9691-- the LD H,07

 

             setting H to =  0       1       2        3      4       5       6       7    etc
muliplied *8              0000/0800/1000/1800/2000/2800/3000/3800  up to f800

 

setting bit 7 of L and multiplying by 8 gives an offset of 400h

.

so by combining  we can have offsets of 

                         0000/0400/0800/0c00/1000/1400  up to Fc00

.

by setting either we have #20 addresses we can use.

anything below #8000 is taken by buffers/screen/rom

 

Giving usable addresses such as (in hex)

 

h=      10     11     12     13     14     15     16    17
          8000,8800,9000,9800,a000,a800,b000,b800    with RES 7,L         REM'ed out
          8400,8c00,9400,9c00,a400,ac00,b400,bc00     with SET 7,L         left in

 

h=      18     19     1a      1b     1c    1d      1e    1f

          c000,c800,d000,d800,e000,e800,f000,f800      with RES 7,L          REM'ed out

          c400,cc00,d400,dc00,e400,ec00,f400,fc00       with SET 7,L          left in

;----------------------------------------------------------------------------------------------------------------------------

 

The font needs to be stored at these addresses (data from above adjusted for font position) e.g.+#100 

h=      10     11     12     13     14     15     16    17
          8100,8900,9100,9900,a100,a900,b100,b900    with RES 7,L         REM'ed out  
          8500,8d00,9500,9d00,a500,ad00,b500,bd00    with SET 7,L         left in
h=      18     19     1a      1b     1c    1d      1e    1f
          c100,c900,d100,d900,e100,e900,f100,f900       with RES 7,L        REM'ed out  
          c500,cd00,d500,dd00,e500,ed00,f500,fd00       with SET 7,L        left in

 

;-----------------------------------------------------------------------------------------------------------------------------

 Plenty of memory addresses to play with

 

(back to decimal)

I would assume you would use a short font, e.g. just ASCII 32 up to ASCII 127 or less

 

I see no point in ASCII above 128 or below 32

 

The stored font then needs to sit 32*8 above the base page (listed above) e.g. +256 with a font size  less than 800 bytes

 

Stored font is (128-32)*8=768


Edited by Norman Sword, 27 January 2018 - 11:02 AM.


#3 Spider

Spider

    DEC (HL)

  • Administrator
  • 2,906 posts

Posted 25 January 2018 - 11:57 PM

Thanks Norman. :) I'll take a closer look at this in the morning.

 

Yes I'd only use a standard 768 byte font, possibly less actually, as with other things I have (in some cases) merely restricted it to 0 to 9 , redefined a few of the symbols present between here and the upper case letters ; : < etc and stopped at Z

 

Mind you having said that the full 768 sets do give more flexibility and saves messing about so much with minor things like remembering to say "move" the Ⓒ symbol from 127 to a 'otherwise unused' one such as @ for instance.

 

I do have a mass erm 'collection' of font sets I need to tidy up before presenting them as some kind of tape file, there is a Basic one already I have written to do this but it wants tidying up as its not really in a sensible release state as such yet.


Edited by Spider, 25 January 2018 - 11:58 PM.

Changing order to chaos since 1984

#4 IRF

IRF

    Advanced Member

  • Contributor
  • 3,419 posts

Posted 26 January 2018 - 01:02 AM

There's a big chunk of unused addresses in the Manic Miner code at #934C through to #9CFF (although the very end of that is used for the stack).

 

So you could either:

 

- Use H=#12 (with the SET 7,L command retained), and insert the font characters at #9500 to #97FF;

 

- Or have H=#13 (and replace the SET 7,L with a RES 7,L), with the font being stored at #9900 to #9BFF.

 

Note that the SET 7,L command is at #92CE in the Manic Miner code (that's in the Bug Byte version, it may be different in the Software Projects variant although I don't think the differences extend that far).


Edited by IRF, 26 January 2018 - 09:29 AM.


#5 Norman Sword

Norman Sword

    Advanced Member

  • Member
  • PipPipPip
  • 120 posts

Posted 26 January 2018 - 08:39 AM

I have added a note to the top of what I wrote, concerning the SET 7,L opcode.



#6 IRF

IRF

    Advanced Member

  • Contributor
  • 3,419 posts

Posted 26 January 2018 - 09:28 AM

Thanks Norman, I've edited my post above as well accordingly.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users