How many different fonts could you have on screen theoretically at the same time?

[Steril707]

Just wondered if it would be feasible to have each line has its on font, on let's say a 128kb equipped machine?

Would be 24 kilobytes then, which is quite a lot. 

 

Is there anything in the architecture preventing this on the Ataris?

[pps]

Actually you can have up to 30 lines (at least PAL machines can show them on screen, NTSC differs by used monitor a lot more) each with a different charset loaded. So 30kB just for the fonts is needed then. 

 

Machine should handle this perfect. 

Edited September 15, 2023 by pps

[tebe]

30, if you want to get rid of "bad lines"

 

240  

they can be switched every line

 

you can also change the set in the middle of the line

 

split_charset_2.asm split_charset_2.obx

Edited September 15, 2023 by tebe

[pps]

44 minutes ago, tebe said:

30, if you want to get rid of "bad lines"

 

240  

they can be switched every line

 

you can also change the set in the middle of the line

Ah, never thought so far... Seems I have to try out something with this (new to me) knowledge 😏

[Rybags]

Unlimited (to an extent)

You also have CHACT which can be used for effects such as vertically inverting the font and turning inverse video on and off.

Would need to check, but fairly sure the v-inversion is an instantaneous thing and just acts on the lower 3 address bits when a character set fetch is performed, ie every scanline during character mode when each character's font data is fetched.

Edited September 15, 2023 by Rybags

[Steril707]

RAM wise, I guess I am limited by the 64kb bank boundary, aren't I?

[tebe]

2 hours ago, Rybags said:

You also have CHACT which can be used for effects such as vertically inverting the font and turning inverse video on and off.

Would need to check, but fairly sure the v-inversion is an instantaneous thing and just acts on the lower 3 address bits when a character set fetch is performed, ie every scanline during character mode when each character's font data is fetched.

I have such an effect in the "drawer" that uses CHACT (Video Reflect) and switching sets every line, there was no such effect on XE/XL yet

[Rybags]

I also devised an effect using CHACT in conjunction with VSCROL tricks.

I'll have to see if I can find it and do something with it - CHACT is somewhat underutilized on our system.

[Steril707]

Once again, how would the RAM setup with like 24 used fonts in let's say Antic 4 look like?

Do I even have enough space in one RAM bank for that?

Edited September 15, 2023 by Steril707

[patjomki]

Bank switched Ram Bank has 16KB but 24 fonts (=24k) fit easily in main ram.

[Steril707]

Thanks to everybody for the replies..

[phaeron]

Keep in mind that you don't need to use the whole character set. It'd create a bunch of small holes, but it's perfectly valid to only use a subset of the full 128 characters and reuse the memory for the other characters for other purposes.

[pirx]

exactly! It'd be fantastic to have an option in MADS to reserve portions of memory and fill the rest with the code as it goes. I mentioned it to @tebe some time ago, but I understand it would be challenging to implement.

[ivop]

1 hour ago, pirx said:

exactly! It'd be fantastic to have an option in MADS to reserve portions of memory and fill the rest with the code as it goes. I mentioned it to @tebe some time ago, but I understand it would be challenging to implement.

What exactly do you mean by this?

 

Reserving memory is usually done with org *+value or .ds value, but I assume you mean something different?

[pirx]

Real-world scenario:

- text mode, each line is a different charset, say 20 lines = 20 fonts.

- I need 54 different characters in each line, which means 432 bytes used in each charset. It means 592 bytes are left unused in each charset.

so the definition would look like this (typing from memory, the syntax might be incorrect):

	align $400
charset01
    ins 'chset01.fnt',,432

	align $400
charset02
    ins 'chset02.fnt',,432
...
	align $400
charset20
    ins 'chset20.fnt',,432

And in RAM I have 

20KiB taken and 19 holes 592 bytes each.

 

Now, imagine you could tell MADS that these holes are free to use... It could fill it up with procedures, tables, and such.

It is definitely not an easy task, maybe even impossible for a cross-assembler - a very simple approach would add jumps around reserved areas. A more sophisticated approach would be to reorganize procs and data chunks to best fit the holes. But it smells like a higher-level language, not an assembler really.

[dmsc]

Hi!

4 hours ago, pirx said:

Real-world scenario:

- text mode, each line is a different charset, say 20 lines = 20 fonts.

- I need 54 different characters in each line, which means 432 bytes used in each charset. It means 592 bytes are left unused in each charset.

so the definition would look like this (typing from memory, the syntax might be incorrect):

	align $400
charset01
    ins 'chset01.fnt',,432

	align $400
charset02
    ins 'chset02.fnt',,432
...
	align $400
charset20
    ins 'chset20.fnt',,432

And in RAM I have 

20KiB taken and 19 holes 592 bytes each.

 

Now, imagine you could tell MADS that these holes are free to use... It could fill it up with procedures, tables, and such.

It is definitely not an easy task, maybe even impossible for a cross-assembler - a very simple approach would add jumps around reserved areas. A more sophisticated approach would be to reorganize procs and data chunks to best fit the holes. But it smells like a higher-level language, not an assembler really.

This is easy to do with CA65/LD65 and a custom linker script: you need to define memory areas for each 1k block, and then add (at least) two segments to each memory area, one with the font and another one with the code.

 

MEMORY {
    ZP:         file = "", define = yes, start = $0082, size = $007E;
    FONT1:      file = %O, define = yes, start = $2000, size = $400;
    FONT2:      file = %O, define = yes, start = $2400, size = $400;
    FONT3:      file = %O, define = yes, start = $2800, size = $400;
    FONT4:      file = %O, define = yes, start = $2C00, size = $400;
    FONT5:      file = %O, define = yes, start = $3000, size = $400;
    FONT6:      file = %O, define = yes, start = $3400, size = $400;
    FONT7:      file = %O, define = yes, start = $3800, size = $400;
    FONT8:      file = %O, define = yes, start = $3C00, size = $400;
    MAIN:       file = %O, define = yes, start = $4000, size = $4000;
}
FILES {
    %O: format = atari;
}
FORMATS {
    atari: runad = start;
}
SEGMENTS {
    ZEROPAGE:  load = ZP,         type = zp;
    FONT1:     load = FONT1,      type = ro, define = yes;
    FONT2:     load = FONT2,      type = ro, define = yes;
    FONT3:     load = FONT3,      type = ro, define = yes;
    FONT4:     load = FONT4,      type = ro, define = yes;
    FONT5:     load = FONT5,      type = ro, define = yes;
    FONT6:     load = FONT6,      type = ro, define = yes;
    FONT7:     load = FONT7,      type = ro, define = yes;
    FONT8:     load = FONT8,      type = ro, define = yes;
    CODE:      load = MAIN,       type = ro;
    CODE1:     load = FONT1,      type = ro;
    CODE2:     load = FONT2,      type = ro;
    CODE3:     load = FONT3,      type = ro;
    CODE4:     load = FONT4,      type = ro;
    CODE5:     load = FONT5,      type = ro;
    CODE6:     load = FONT6,      type = ro;
    CODE7:     load = FONT7,      type = ro;
    CODE8:     load = FONT8,      type = ro;
    DATA:      load = MAIN,       type = rw;
}

 

You then need to assign different procedures / tables to different segments CODE, CODE1, CODE2, etc., like this:

 

	.segment "FONT1"
	.byte  1,2,3,4,.....

	.segment "FONT2"
	.byte  1,2,3,4,.....

	.segment "FONT3"
	.byte  1,2,3,4,.....

	.segment "CODE1"
	.proc my_proc
	; ....
	.endproc

	.segment "CODE2"
	.proc my_table
	.byte 1,2,3,4,....
	.endproc

	.segment "CODE1"
	.proc other_proc
	; ....
	.endproc

	;... and so on...

 

Note that the order does not matter, as the linker script specify that the "FONT" segments are at the start of each memory section.

 

What LD65 does not (yet) support is writing a segment to more than one memory area, you need to specify on which area each segment is written and then assign a segment manually to each procedure, but IMHO, this would not be difficult to implement. I would like a syntax similar to the GNU LD linker, where you can specify segments with a pattern (like, "code.*"), and then each procedure can be written to a different segment and sorted accordingly.

 

Have Fun!

[+Stephen]

1 hour ago, dmsc said:

Hi!

6 hours ago, pirx said:

Real-world scenario:

- text mode, each line is a different charset, say 20 lines = 20 fonts.

- I need 54 different characters in each line, which means 432 bytes used in each charset. It means 592 bytes are left unused in each charset.

so the definition would look like this (typing from memory, the syntax might be incorrect):

	align $400
charset01
    ins 'chset01.fnt',,432

	align $400
charset02
    ins 'chset02.fnt',,432
...
	align $400
charset20
    ins 'chset20.fnt',,432

And in RAM I have 

20KiB taken and 19 holes 592 bytes each.

 

Now, imagine you could tell MADS that these holes are free to use... It could fill it up with procedures, tables, and such.

It is definitely not an easy task, maybe even impossible for a cross-assembler - a very simple approach would add jumps around reserved areas. A more sophisticated approach would be to reorganize procs and data chunks to best fit the holes. But it smells like a higher-level language, not an assembler really.

Expand  

This is easy to do with CA65/LD65 and a custom linker script: you need to define memory areas for each 1k block, and then add (at least) two segments to each memory area, one with the font and another one with the code.

That's fantastic!

[tebe]

21 hours ago, pirx said:

Real-world scenario:

- text mode, each line is a different charset, say 20 lines = 20 fonts.

- I need 54 different characters in each line, which means 432 bytes used in each charset. It means 592 bytes are left unused in each charset.

so the definition would look like this (typing from memory, the syntax might be incorrect):

	align $400
charset01
    ins 'chset01.fnt',,432

	align $400
charset02
    ins 'chset02.fnt',,432
...
	align $400
charset20
    ins 'chset20.fnt',,432

And in RAM I have 

20KiB taken and 19 holes 592 bytes each.

 

Now, imagine you could tell MADS that these holes are free to use... It could fill it up with procedures, tables, and such.

It is definitely not an easy task, maybe even impossible for a cross-assembler - a very simple approach would add jumps around reserved areas. A more sophisticated approach would be to reorganize procs and data chunks to best fit the holes. But it smells like a higher-level language, not an assembler really.

use G2F

Special -> Limitations -> First Char ; Last Char

[Cyprian]

On 9/15/2023 at 11:41 AM, tebe said:

30, if you want to get rid of "bad lines"

 

240  

they can be switched every line

 

you can also change the set in the middle of the line

 

split_charset_2.asm 1.29 kB · 7 downloads split_charset_2.obx 2.2 kB · 8 downloads

I wonder what is the advantage (besides 5th color) of char mode over bitmap mode in this particular screen?

[Irgendwer]

3 minutes ago, Cyprian said:

I wonder what is the advantage (besides 5th color) of char mode over bitmap mode in this particular screen?

That you can flip the charset in-line and so quickly the visualization contrary to bitmap, where you would have to copy the contents which is not possible in this speed...

[Rybags]

With the swirl effect where you have image change that can occur practically anywhere, the only way you could do that in bitmap is by bankswitching on a 128K or higher machine.

Additionally to enable the character set change on any line, there's VSCROL tricks in use so that there's only a badline at the top of the window, otherwise you'd not be able to do the change in hires char modes on the first scanline of each character.

[atarixle]

Why using whole fonts each 1024 Bytes in size, when you can display only 40 (or 48) characters?

In three lines you could represent e.g. the letter 'A' by 8 Bytes of the data of 120 different fonts.

Edited October 4, 2023 by atarixle

[Rybags]

VScrol tricks to create shorter characters mean you can have the PF2/PF3 choice in a smaller area.

It can become wasteful though.

A good compromise can be using 4 scanline high chars, then you can use CHACT to flip the characters such that the entirety of the font data is used.

Though if you're doing a bitmap simulation you'd likely be using 120 characters only so 8 would go to waste.