Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » Apple /// Font Loading: Success
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Apple /// Font Loading: Success [message #372002] Fri, 10 August 2018 21:28 Go to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
So I managed to write what I've been trying to write, by combining the two
functions from the ROM and SOS, what I've been trying to do all along:

ctemp1 = $FD

dnldcel = $FE
dnldchr = $FF
dimgptr = $06
dcelptr = $08

fontptr = $9000

cwrton = $C0DB
cwrtoff = $C0DA
cb2ctrl = $FFEC
cb2int = $FFED

.org $1000

loadfnt: lda #<fontptr
sta dimgptr
lda #>fontptr
sta dimgptr+1
lda #$00
sta dnldchr
lda #$07
sta dnldcel
@1: jsr loadchr
dec dnldcel
bpl @2
bit cwrton
jsr vretrce
jsr vretrce
bit cwrtoff
lda #$07
sta dnldcel
@2: inc dnldchr
bpl @1
rts

loadchr: lda #$00 ; X will be set to 0 for this function
tax
tay ; Use Y for row counter
@1: lda dnldcel ; Set up cell pointer for ASCII code
and #$03
ora dcptrl, y
sta dcelptr, x
lda dnldcel
lsr
lsr
cpy #$04
rol
ora #$08
sta dcelptr+1, x
lda dnldchr ; Store ASCII code into download cell
sta (dcelptr, x)
lda dcelptr+1, x ; Fix cell pointer for character
image
eor #$0C
sta dcelptr+1, x
lda (dimgptr, x) ; Store character image
sta (dcelptr, x) ; into download cell
inc dimgptr, x ; Increment the image pointer
bne @2
inc dimgptr+1, x
@2: iny ; Increment the row number
cpy #$08
bcc @1 ; Not done yet
rts

vretrce: sta ctemp1 ; save bits to be stored
lda cb2ctrl ; control port for "CB2"
and #$3F ; reset high bits to 0
ora ctemp1
sta cb2ctrl
lda #$08 ; test vertical retrace
sta cb2int
vwait: bit cb2int ; wait for retrace
beq vwait
rts

dcptrl: .byte $78, $7C, $F8, $FC, $78, $7C, $F8, $FC

Alright, so what next?

Here ya go: http://3.buric.co/autostar.zip

To make things easier for me I downgraded to a bogstock 1980 DOS 3.3.
That gave me more breathing room to put in my patches to the bootloader.

The "DOS 3.3 IPL" code is shoved into an empty sector, and "STAR EMULATOR
0.5" (the actual name is irrelevant; all the loader checks is that the
first file in the directory is of type S) must be the first file in the
directory.

Boot the disk, you'll see this message at the top of the screen (what
appears in brackets is the filename):

[STAR EMULATOR 0.5 ] SZ=$37

Then the screen will blank briefly, and you'll see the familiar ], and
it'll be the Apple ][ system font ], not the squished Apple /// system
font ].

So now everything I've been relying on SOS for - set up the font, load the
program into memory - I don't need any of it anymore. A little bit is
done by the ROM - rest is done manually.

As for the above code, what if you want to load an Apple ][ font (DOS
Toolkit, Beagle Graphics), could you do that? Yes:

]FOR I=36864 TO 37119:POKE I,0:NEXT
]BLOAD filename.set,A$9100
]CALL 4096

(The code could be altered easily enough to use a different work address.)

-uso.
Re: Apple /// Font Loading: Success [message #372017 is a reply to message #372002] Sat, 11 August 2018 10:21 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Steve Nickolas <usotsuki@buric.co> wrote:
> So I managed to write what I've been trying to write, by combining the two
> functions from the ROM and SOS, what I've been trying to do all along:
>
> ctemp1 = $FD
>
> dnldcel = $FE
> dnldchr = $FF
> dimgptr = $06
> dcelptr = $08
>
> fontptr = $9000
>
> cwrton = $C0DB
> cwrtoff = $C0DA
> cb2ctrl = $FFEC
> cb2int = $FFED
>
> .org $1000
>
> loadfnt: lda #<fontptr
> sta dimgptr
> lda #>fontptr
> sta dimgptr+1
> lda #$00
> sta dnldchr
> lda #$07
> sta dnldcel
> @1: jsr loadchr
> dec dnldcel
> bpl @2
> bit cwrton
> jsr vretrce
> jsr vretrce
> bit cwrtoff
> lda #$07
> sta dnldcel
> @2: inc dnldchr
> bpl @1
> rts
>
> loadchr: lda #$00 ; X will be set to 0 for this function
> tax
> tay ; Use Y for row counter
> @1: lda dnldcel ; Set up cell pointer for ASCII code
> and #$03
> ora dcptrl, y
> sta dcelptr, x
> lda dnldcel
> lsr
> lsr
> cpy #$04
> rol
> ora #$08
> sta dcelptr+1, x
> lda dnldchr ; Store ASCII code into download cell
> sta (dcelptr, x)
> lda dcelptr+1, x ; Fix cell pointer for character
> image
> eor #$0C
> sta dcelptr+1, x
> lda (dimgptr, x) ; Store character image
> sta (dcelptr, x) ; into download cell
> inc dimgptr, x ; Increment the image pointer
> bne @2
> inc dimgptr+1, x
> @2: iny ; Increment the row number
> cpy #$08
> bcc @1 ; Not done yet
> rts
>
> vretrce: sta ctemp1 ; save bits to be stored
> lda cb2ctrl ; control port for "CB2"
> and #$3F ; reset high bits to 0
> ora ctemp1
> sta cb2ctrl
> lda #$08 ; test vertical retrace
> sta cb2int
> vwait: bit cb2int ; wait for retrace
> beq vwait
> rts
>
> dcptrl: .byte $78, $7C, $F8, $FC, $78, $7C, $F8, $FC
>
> Alright, so what next?
>
> Here ya go: http://3.buric.co/autostar.zip
>
> To make things easier for me I downgraded to a bogstock 1980 DOS 3.3.
> That gave me more breathing room to put in my patches to the bootloader.
>
> The "DOS 3.3 IPL" code is shoved into an empty sector, and "STAR EMULATOR
> 0.5" (the actual name is irrelevant; all the loader checks is that the
> first file in the directory is of type S) must be the first file in the
> directory.
>
> Boot the disk, you'll see this message at the top of the screen (what
> appears in brackets is the filename):
>
> [STAR EMULATOR 0.5 ] SZ=$37
>
> Then the screen will blank briefly, and you'll see the familiar ], and
> it'll be the Apple ][ system font ], not the squished Apple /// system
> font ].
>
> So now everything I've been relying on SOS for - set up the font, load the
> program into memory - I don't need any of it anymore. A little bit is
> done by the ROM - rest is done manually.
>
> As for the above code, what if you want to load an Apple ][ font (DOS
> Toolkit, Beagle Graphics), could you do that? Yes:
>
> ]FOR I=36864 TO 37119:POKE I,0:NEXT
> ]BLOAD filename.set,A$9100
> ]CALL 4096
>
> (The code could be altered easily enough to use a different work address.)
>
> -uso.
>

Congrats, Steve!

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Apple /// Font Loading: Success [message #372084 is a reply to message #372017] Sun, 12 August 2018 21:37 Go to previous messageGo to next message
Rob Justice is currently offline  Rob Justice
Messages: 98
Registered: January 2013
Karma: 0
Member
On Sunday, August 12, 2018 at 12:21:36 AM UTC+10, Michael J. Mahon wrote:
> Steve Nickolas wrote:
>> So I managed to write what I've been trying to write, by combining the two
>> functions from the ROM and SOS, what I've been trying to do all along:
>>
>> ctemp1 = $FD
>>
>> dnldcel = $FE
>> dnldchr = $FF
>> dimgptr = $06
>> dcelptr = $08
>>
>> fontptr = $9000
>>
>> cwrton = $C0DB
>> cwrtoff = $C0DA
>> cb2ctrl = $FFEC
>> cb2int = $FFED
>>
>> .org $1000
>>
>> loadfnt: lda #<fontptr
>> sta dimgptr
>> lda #>fontptr
>> sta dimgptr+1
>> lda #$00
>> sta dnldchr
>> lda #$07
>> sta dnldcel
>> @1: jsr loadchr
>> dec dnldcel
>> bpl @2
>> bit cwrton
>> jsr vretrce
>> jsr vretrce
>> bit cwrtoff
>> lda #$07
>> sta dnldcel
>> @2: inc dnldchr
>> bpl @1
>> rts
>>
>> loadchr: lda #$00 ; X will be set to 0 for this function
>> tax
>> tay ; Use Y for row counter
>> @1: lda dnldcel ; Set up cell pointer for ASCII code
>> and #$03
>> ora dcptrl, y
>> sta dcelptr, x
>> lda dnldcel
>> lsr
>> lsr
>> cpy #$04
>> rol
>> ora #$08
>> sta dcelptr+1, x
>> lda dnldchr ; Store ASCII code into download cell
>> sta (dcelptr, x)
>> lda dcelptr+1, x ; Fix cell pointer for character
>> image
>> eor #$0C
>> sta dcelptr+1, x
>> lda (dimgptr, x) ; Store character image
>> sta (dcelptr, x) ; into download cell
>> inc dimgptr, x ; Increment the image pointer
>> bne @2
>> inc dimgptr+1, x
>> @2: iny ; Increment the row number
>> cpy #$08
>> bcc @1 ; Not done yet
>> rts
>>
>> vretrce: sta ctemp1 ; save bits to be stored
>> lda cb2ctrl ; control port for "CB2"
>> and #$3F ; reset high bits to 0
>> ora ctemp1
>> sta cb2ctrl
>> lda #$08 ; test vertical retrace
>> sta cb2int
>> vwait: bit cb2int ; wait for retrace
>> beq vwait
>> rts
>>
>> dcptrl: .byte $78, $7C, $F8, $FC, $78, $7C, $F8, $FC
>>
>> Alright, so what next?
>>
>> Here ya go: http://3.buric.co/autostar.zip
>>
>> To make things easier for me I downgraded to a bogstock 1980 DOS 3.3.
>> That gave me more breathing room to put in my patches to the bootloader..
>>
>> The "DOS 3.3 IPL" code is shoved into an empty sector, and "STAR EMULATOR
>> 0.5" (the actual name is irrelevant; all the loader checks is that the
>> first file in the directory is of type S) must be the first file in the
>> directory.
>>
>> Boot the disk, you'll see this message at the top of the screen (what
>> appears in brackets is the filename):
>>
>> [STAR EMULATOR 0.5 ] SZ=$37
>>
>> Then the screen will blank briefly, and you'll see the familiar ], and
>> it'll be the Apple ][ system font ], not the squished Apple /// system
>> font ].
>>
>> So now everything I've been relying on SOS for - set up the font, load the
>> program into memory - I don't need any of it anymore. A little bit is
>> done by the ROM - rest is done manually.
>>
>> As for the above code, what if you want to load an Apple ][ font (DOS
>> Toolkit, Beagle Graphics), could you do that? Yes:
>>
>> ]FOR I=36864 TO 37119:POKE I,0:NEXT
>> ]BLOAD filename.set,A$9100
>> ]CALL 4096
>>
>> (The code could be altered easily enough to use a different work address.)
>>
>> -uso.
>>
>
> Congrats, Steve!
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

Yes, nice work!

Its something I have been going to have a look at as well as the game Atomic Defense does not load its fonts correctly in MAME A3 emulation. MAME just loads the fonts when the enable char write is turned on. It looks like it should load the font memory every time the video scanner runs through, so each VBL if the enchrwrt is on. if you update the screen holes without turning the enchrwrt off and on, it misses the update.

You know I did not notice that the startup font for the Apple /// was squashed like that. It is a row shorter, must be due to rom space limitations. If you run the A3+ diagnostics disk, it loads the normal font in and you can notice the change after it boots. Its very clear.

/Rob
Re: Apple /// Font Loading: Success [message #372088 is a reply to message #372084] Mon, 13 August 2018 01:33 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Sun, 12 Aug 2018, Rob Justice wrote:

> Its something I have been going to have a look at as well as the game
> Atomic Defense does not load its fonts correctly in MAME A3 emulation.
> MAME just loads the fonts when the enable char write is turned on. It
> looks like it should load the font memory every time the video scanner
> runs through, so each VBL if the enchrwrt is on. if you update the
> screen holes without turning the enchrwrt off and on, it misses the
> update.

Unfortunately MAME is all I've got. .-.

> You know I did not notice that the startup font for the Apple /// was
> squashed like that. It is a row shorter, must be due to rom space
> limitations. If you run the A3+ diagnostics disk, it loads the normal
> font in and you can notice the change after it boots. Its very clear.

I think it is ROM space limitations, because it's actually stored
compressed down to a mere 239 bytes (instead of 1024).

In addition to being a squished font, it only has 64 glyphs, with the
other 64 (underline) being automatically generated from the first.

-uso.
Re: Apple /// Font Loading: Success [message #373894 is a reply to message #372002] Sat, 22 September 2018 09:15 Go to previous messageGo to next message
David Schmidt is currently offline  David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
Senior Member
On 8/10/2018 9:28 PM, Steve Nickolas wrote:
> So I managed to write what I've been trying to write, by combining the
> two functions from the ROM and SOS, what I've been trying to do all along:

I've repeated your results in my code. What I have been doing in ADTPro
on SOS is to include the .CONSOLE driver, which even if you don't open
it, it will load and enable the fatter font for you. But I can shave
off 6-7k from loading by using your font and loader instead, which is a
nice bonus especially for bootstrapping operations. Plus, I get to
annoy the System Configuration Program by making it complain: "Warning -
you don't have an active CONSOLE driver!" Muahahaha, don't tell *me*
what I can and can't do, SCP!
Re: Apple /// Font Loading: Success [message #373909 is a reply to message #373894] Sat, 22 September 2018 13:52 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Sat, 22 Sep 2018, David Schmidt wrote:

> On 8/10/2018 9:28 PM, Steve Nickolas wrote:
>> So I managed to write what I've been trying to write, by combining the two
>> functions from the ROM and SOS, what I've been trying to do all along:
>
> I've repeated your results in my code.

So it does work on metal? That concerned me because MAME's Apple ///
emulation isn't always the best.

(One of these days I really need to find a ///, preferably a ///+ so I
don't have to do the /// Inch Drop. XP)

> What I have been doing in ADTPro on SOS is to include the .CONSOLE
> driver, which even if you don't open it, it will load and enable the
> fatter font for you. But I can shave off 6-7k from loading by using
> your font and loader instead, which is a nice bonus especially for
> bootstrapping operations.

Basically, the same reason I wanted to figure out how to use it - so I
didn't have to load SOS and the console driver just to be able to go boot
into DOS 3.3 with all my special junk resident.

> Plus, I get to annoy the System Configuration Program by making it
> complain: "Warning - you don't have an active CONSOLE driver!"
> Muahahaha, don't tell *me* what I can and can't do, SCP!

XD

-uso.
Re: Apple /// Font Loading: Success [message #373920 is a reply to message #373909] Sat, 22 September 2018 19:07 Go to previous messageGo to next message
David Schmidt is currently offline  David Schmidt
Messages: 993
Registered: October 2012
Karma: 0
Senior Member
On 9/22/2018 1:52 PM, Steve Nickolas wrote:
> On Sat, 22 Sep 2018, David Schmidt wrote:
>
>> On 8/10/2018 9:28 PM, Steve Nickolas wrote:
>>> So I managed to write what I've been trying to write, by combining
>>> the two functions from the ROM and SOS, what I've been trying to do
>>> all along:
>>
>> I've repeated your results in my code.
>
> So it does work on metal? That concerned me because MAME's Apple ///
> emulation isn't always the best.

Yes, it does work on metal. I have mixed results with my code that uses
the CONSOLE driver in MESS/MAME, but otherwise I have had really good
luck with Arbee's emulator. My CONSOLE problems are what drove me to
transplant the /// monitor ROM for screen I/O in 40 columns. Now that I
want to do 80 columns too, I am looking at transplanting the screen
manipulating guts of CONSOLE into code to do raw screen I/O instead.

> (One of these days I really need to find a ///, preferably a ///+ so I
> don't have to do the /// Inch Drop. XP)

Yep. You do. They all require TLC, but they are very rewarding.

>> What I have been doing in ADTPro on SOS is to include the .CONSOLE
>> driver, which even if you don't open it, it will load and enable the
>> fatter font for you.  But I can shave off 6-7k from loading by using
>> your font and loader instead, which is a nice bonus especially for
>> bootstrapping operations.
>
> Basically, the same reason I wanted to figure out how to use it - so I
> didn't have to load SOS and the console driver just to be able to go
> boot into DOS 3.3 with all my special junk resident.

I still need SOS underlying my particular applications (ADTPro, Dav3x)
but CONSOLE is just so incredibly slow and inflexible. It's really not
practical for anything but a form-filling application.
Re: Apple /// Font Loading: Success [message #373924 is a reply to message #373920] Sat, 22 September 2018 20:37 Go to previous message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Sat, 22 Sep 2018, David Schmidt wrote:

> Yes, it does work on metal. I have mixed results with my code that uses the
> CONSOLE driver in MESS/MAME, but otherwise I have had really good luck with
> Arbee's emulator. My CONSOLE problems are what drove me to transplant the
> /// monitor ROM for screen I/O in 40 columns. Now that I want to do 80
> columns too, I am looking at transplanting the screen manipulating guts of
> CONSOLE into code to do raw screen I/O instead.

I've actually been trying to write a console driver of my own (sitting on
top, currently, of DOS 3.3) that supports the Apple /// functionality. I
got it working great with 40-column color mode, but it...doesn't quite
work as I'd like it to for 80-column mode, and the 80-column support would
need some work to properly integrate.

What we really need is an "Appl3Win"... XD

-uso.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Particles! BBS
Next Topic: wondering if anyone might have an Option Key for an Apple IIc+ keyboard?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 13:54:31 EDT 2024

Total time taken to generate the page: 0.10247 seconds