fonts 4x8

[snicklin]

2 hours ago, David_P said:

Best you can do for 80 columns would be a Flickerterm type solution: 1K for a modified character set, and 2K for the two screens.

 

An 80 column screen = 80x24 = 1920 bytes at a minimum, even if it was a native mode supported by hardware.

I forgot to double the number of bytes for holding the screen contents, oops, of course! It was where I saw the line drawing, I thought it might be compulsory to have graphics capabilities. And I wasn't sure if text was being drawn to graphics mode 8 in order to achieve 4x8 fonts. 2k would be Ok for me, 8k would stop me using it.

[xxl]

6 hours ago, snicklin said:

I am working on a text based game which would benefit a lot from 80 char text.

what does your Display List look like?

[Mark2008]

On 12/28/2020 at 8:30 AM, danwinslow said:

This calls them 'handlers' but it's the same thing.

https://www.atarimagazines.com/v8n2/customhandlers.html

 

 

Usually at this point I have conversation that goes something like - OK I've read the article but I still have some questions.

   Are you sure you read it?    yes, I really read it.
   But are you sure you read it? yes.
  Really?   OK I SCANNED IT!!

 

haha, pure silliness, anyway, looking at:

 

https://www.atarimagazines.com/compute/issue20/166_1_INSIGHT_ATARI.php

 

What I grok from this, is at the highest level,  each device handler address is placed into the handler address table, and conforms to rules.
Specifically it will provide at least six subroutines and an initialization subroutine.  And we know they are OPEN, CLOSE, PUTBYTE, GETBYTE, STATUS and XIO.

 

https://www.atarimagazines.com/v8n3/OperatingSystemHandlers.html

 

They mention the screen editor handler, and are JSR to EPUT or EGET which are vectored to PUT BYTE and GET BYTE.

What I think - correct if wrong, is that this is way more complex than these articles hint.  

 

The reason I say that is AtariAge posts that I've read from time to time that hint at much more complexity. 

 

 

 

Phaeron mentions complex rules between physical lines and logical lines.  My guess is what Phaeron does is disassembles drivers and examines how things work to re-engineer.  I need kind of a tutorial for a helpless baby that won't do a thing to figure the problem out.

 

Anyway, I've talked myself out of it, at this point.  

 

Of course, I want to stress this thread is absolutely fantastic.  A fast, small e: driver, for software that does use e: driver is great.  And the windowing system looks fantastic!

 

 

But I just mean my specific use case, I would want 80-columns as a hardware overlay, in order to intermix text and graphics and that means vbxe.  No magic way to gift that ability to a software driver using graphics 8.

Plus, if I talk myself out of it, problem solved....neat!!!!

[snicklin]

13 hours ago, xxl said:

what does your Display List look like?

On some screens in the game, it is a normal graphics 0 screen.

 

And one some screens, it is a normal graphics 0 screen but with DLIs enabled on each line to be able to change the background colour.

 

[+David_P]

Quad width players and the missiles underlaid on the screen can also be used to add background colour without needing DLIs.

[snicklin]

4 hours ago, David_P said:

Quad width players and the missiles underlaid on the screen can also be used to add background colour without needing DLIs.

Hmm, I could use pms and so forth, but that is a lot of extra overhead. I also want the option to later add a cursor for a mouse (for a latter revision of my software). If 80 column text is not possible for what I want, OK, but it would be a great extra. I am working on a football (soccer) management game and 80 columns would be great for statistics, though I have currently coded for 40 columns.

 

Memory is really tight due to having player and team information in memory.

Edited January 23, 2021 by snicklin

[xxl]

1 hour ago, snicklin said:

Memory is really tight due to having player and team information in memory.

but my 80 column driver requires graphics mode (GR.8) where one line of text on the screen takes 320 bytes for the standard screen width (40 bytes x 8 )  

Edited January 23, 2021 by xxl

[danwinslow]

19 hours ago, Mark2008 said:

 

Usually at this point I have conversation that goes something like - OK I've read the article but I still have some questions.

   Are you sure you read it?    yes, I really read it.
   But are you sure you read it? yes.
  Really?   OK I SCANNED IT!!

 

 

Well, the handler INTERFACE is simple, but behind it can be very complicated of course. It's just kind of a standard example of abstraction, which is so common now we don't really even notice it. But at the time, it was a revolutionary step for a home computer, absolutely ahead of its time.

[snicklin]

On 23/01/2021 at 6:20 PM, xxl said:

but my 80 column driver requires graphics mode (GR.8) where one line of text on the screen takes 320 bytes for the standard screen width (40 bytes x 8 )  

OK, that is good to know. I won't use it, but it still looks like an excellent development,

Edited January 24, 2021 by snicklin

[+Andrew Davie]

There's a super-nice 4-pixel wide font on the '2600 named "Glacier Belle".  It's 12 scanlines high, but I thought I'd mention it just in case it might be useful... here's a screenshot of an earlier version of the font.  It's particularly nice in the lowercase. Happy to share the binary data if useful.

 

[OxC0FFEE]

@xxl any updates on this? I'd love a nice windowed, readable 80-col driver.

[Nezgar]

Would it be possible to hide the screen buffer under the basic rom in XL/XE? Then at least for BASIC programs there's no apparent additional loss from the 8K screenbuffer. Handler switches off basic ROM for any changes to the screen, DLI's to turn off basic ROM during screen draw. I guess this could slow down the drawing?

 

I guess hiding it under OS is another possibility, but harder/ slower.

[tebe]

summary

8x4.fnt 8x4int.fnt 8x4pl.fnt

[thorfdbg]

On 12/25/2021 at 5:09 AM, Nezgar said:

Would it be possible to hide the screen buffer under the basic rom in XL/XE?

Nope. There is no separate RAM access for CPU and Antic. Either both access the RAM, or both access the ROM.

[Nezgar]

1 hour ago, thorfdbg said:

There is no separate RAM access for CPU and Antic. Either both access the RAM, or both access the ROM.

Right... PortB bit 5 on a 130XE would allow Antic to display extended banked RAM independent of CPU selection on bit 4... but of course I see what you mean this doesn't apply for RAM under ROM.

 

But.. My thought was to use a DLI to switch the ROM off when drawing the screen, and back on at the end of the frame... maybe impossible since too many other OS dependancies/interrupts would interfere....

[thorfdbg]

And, when you turn the ROM back on, ANTIC will also read from ROM and ignore the data just written. Thus, the ROM must be off whenever the display is active. Thus, in best case, you cannot execute anything in ROM the majority o f time.