Jump to content
  • entries
    143
  • comments
    451
  • views
    174,012

Next demo


mos6507

737 views

While waiting for the new board, Delicon has agreed to work on the text engine this week.

 

For the proof of concept, I'm only asking that he preload the fast queues with a fixed text message utilizing the extracted Atari 8-bit home computer font.

 

I have a 7-bit character kernel ready for this use. I have been so far unable to apply Supercat's advice to modifying the kernel to be 8-bit gapless. I was kinda hoping he'd do the honors for me ;) However, I've begun finally get more familiar with the Stella debugger.

 

I plan on doing some cool things with the fonts. With the standard Atari font, it has lowercase letters but they don't descend. The fonts are laid out to be 8x8 (well, actually less than that because there needs to be gaps between them). But there is an OS mode that makes the lowercase characters descend properly. Doing that means extending the height of each row of text by a few scanlines and conditionally dropping the character down. I think we should be able to do this also with Chimera. Because of space considerations, text on Atari games is usually a very limited uppercase only character set. But we'll be able to support all the special characters of the Atari 8-bit with inverse video.

 

The end result should look somewhat similar to these two familiar Atari 8-bit graphics modes.

 

gr1.jpg

 

gr2.jpg

 

Just imagine them being constrained to only 12-characters and only one color setting per row, and with the usual Stellar Track flicker.

 

I've included the bin and source to the most advanced text kernel I have so far. It reads static FFs from ROM currently. When the queues are active, the solid blocks will be transformed with full text graphics. If some enterprising soul would like to fix the kernel to make it gapless, they get a free Chimera board. Knowing my skills, I probably won't be able to do it.

9 Comments


Recommended Comments

In this kernel the text drawing area is effectively 7-bits because of how it's using the HMOVE fine control to shift the sprites back and forth on every line. As Supercat stated, you'd have to exploit the behavior of hitting HMOVE on cycle 74 to get +/-8 pixels. And to do this you have to remove the WSYNC and perfectly time the kernel. I haven't had time to hack at this.

Link to comment

And to do this you have to remove the WSYNC and perfectly time the kernel.

That's far too easy for a free Chimera. ;)

println
;-------------------------
;...
;---------------------------------------------------
ldx	 #4
sta	 WSYNC
pause
nop
dex
bne	 pause
lda	 temp
lda	 temp

sta	 HMCLR
ldx	 #$80			   ;	   +8
ldy	 #FONTHEIGHT		;	  
lda	 frame
and	 #$01
beq	 oddFrame
jmp	 evenFrame

;THIS IS IT
print1
sta	 GRP1			   ; 3
lda	 CH_QUEUE_FAST+4	; 4		 
sta.w   GRP0			   ; 4
lda	 CH_QUEUE_FAST+6	; 4		 
stx.w   HMP0			   ; 4
stx	 HMP1			   ; 3
sta	 GRP1			   ; 3
lda	 CH_QUEUE_FAST+8	; 4		 
sta.w   GRP0			   ; 4
lda	 CH_QUEUE_FAST+10   ; 4		 
sta.w   GRP1			   ; 4
sta	 GRP0			   ; 3
evenFrame					  ;	   @50
dey						; 2
bmi	 wrapEven		   ; 2³
lda	 CH_QUEUE_FAST+1	; 4		 
nop						; 2
sta.w   GRP0			   ; 4
lda	 CH_QUEUE_FAST+3	; 4		 
nop						; 2
nop						; 2
sta	 GRP1			   ; 3
;---------------------------------------
sta	 HMOVE			  ; 3	 @02
lda	 CH_QUEUE_FAST+5	; 4		 
nop						; 2
sta.w   GRP0			   ; 4
lda	 CH_QUEUE_FAST+9	; 4		 
nop						; 2
sta.w   temp			   ; 4
lda	 CH_QUEUE_FAST+7	; 4		 
nop						; 2
sta.w   GRP1			   ; 4
lda	 temp			   ; 3
sta	 GRP0			   ; 3
lda	 CH_QUEUE_FAST+11   ; 4		 
nop						; 2
sta.w   GRP1			   ; 4

oddFrame					   ;	   @48
sta	 GRP0			   ; 3
lda	 #$00			   ; 2	 -8
sta	 HMP0			   ; 3
sta	 HMP1			   ; 3
dey						; 2
bmi	 wrapOdd			; 2³
lda	 CH_QUEUE_FAST+0	; 4		 
sta	 GRP0			   ; 4
;---------------------------------------
sta	 HMOVE			  ; 4	 @73
nop
lda	 CH_QUEUE_FAST+2	; 4		 

  ;THIS IS IT

jmp	 print1			 ; 3

Link to comment

And to do this you have to remove the WSYNC and perfectly time the kernel.

That's far too easy for a free Chimera. ;)

 

Thanks so much, Thomas! I'll try that out when I get home.

 

If that's too easy, though, you could try converting other kernels. The next on the list is Suicide Mission.

Link to comment

If that's too easy, though, you could try converting other kernels. The next on the list is Suicide Mission.

What exactly should I convert there? The title screen?

Link to comment

You'd pull the portion of the code out that displays the in-game bitmap and instead of pulling data from Supercharger RAM, have it just read from the queue hotspots.

 

This could throw off the timing in the kernel depending on the addressing modes used.

 

So you'd wind up with a vanilla 4K program that displays the Suicide Mission kernel but the graphics don't change on every line. When run on an emulator you'd just hardcode FFs into the queue hotspots to verify that the kernel works. That's what I did with the text kernel. The text kernel just shows solid blocks on an emulator.

 

If the RAM overhead is small enough it might be possible to do a chronocolor effect with Suicide Mission. There is only 4K of ARM RAM reserved for bitmaps.

Link to comment

This could throw off the timing in the kernel depending on the addressing modes used.

Which should be pretty easy to fix.

 

So you'd wind up with a vanilla 4K program that displays the Suicide Mission kernel but the graphics don't change on every line.

Sounds simple enough.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...