Jump to content

Photo

36 Character Demo

36 Character

38 replies to this topic

#1 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • 6,186 posts
  • Location:Canada

Posted Fri May 11, 2018 12:36 PM

Here is a 36 character text demo. Check it out. :)

 

Attached File  36_Char_201805011.zip   12.55KB   60 downloads



#2 DirtyHairy OFFLINE  

DirtyHairy

    Moonsweeper

  • 399 posts
  • Location:Germany

Posted Fri May 11, 2018 12:58 PM

Nice! I have hacked together a PAL version (see attachment). On our LCD, the text is perfectly readable (although the TV swallows every odd line) and the flicker is fully filtered by the TV.

 

Attached File  36_Char_201805011_PAL.bin   4KB   29 downloads



#3 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • 1,889 posts

Posted Sat May 12, 2018 10:59 AM

This one looks awesome, the block characters are easy on the eyes and the color scheme makes the flicker nearly imperceptible.
 
Would make a great engine for a text adventure! :)


#4 kdgarris OFFLINE  

kdgarris

    Moonsweeper

  • 319 posts

Posted Sat May 12, 2018 11:19 AM

Or NetHack:2600. ;)

#5 nanochess OFFLINE  

nanochess

    Processorus Polyglotus

  • 5,387 posts
  • Coding something good
  • Location:Mexico City

Posted Sat May 12, 2018 11:56 AM

Amazing! :) :thumbsup:



#6 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Sat May 12, 2018 12:20 PM

Amazing! :) :thumbsup:

Thanks!

 

I had a couple of vacation days so I played around and came up with this. I really do believe a properly aligned 36 character routine is accessible. I'm sure someone will do it, but I am out of time myself. It is just a matter of finding a combination of spacing and techniques that work. I've tried experimenting with VDELPx and 3 copies medium spacing as some techniques for example.

 

The 'B' kernel I made had many cycles left, and the 'A' Kernel was completely full. It was full because I had one nasty spot where I was updating the graphics for GRP0 while the current sprite was still been drawn. So I had to do an extra hybrid write that had the trail end of the existing sprite, and the beginning of the new sprite. Even then I still had to use the ball to cover up one pixel. Incidently kernel 'B' is also the one with bad alignment so it would be nice if it could be fixed. However In the end I believe a perfectly aligned display will probably require two completely new kernels. 



#7 Keatah OFFLINE  

Keatah

    Missile Commander

  • 20,567 posts

Posted Sat May 12, 2018 1:25 PM

Word processors and text adventures!



#8 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Sun May 13, 2018 1:34 PM

Here is a perfectly aligned 36 character demo that is a mock-up for CDF or DPC+. After I made it I realized the irony that I am actually doing the display on stock hardware and that it is perfectly aligned. It uses immediate loads to mock the 2 cycle fast fetch loads that CDF and DPC+ do. This is not the droid I was looking for, but at least it proves the 2600 is capable of doing a perfectly aligned 36 character display on stock hardware. I do still believe the perfectly aligned 36 character routine in which the data can be loaded from zero page ram is accessible using stock hardware. That is the next bar to reach. Somebody will do it.

 

With CDF or DPC+ 40 characters should be the target. I don't know if we can get there, but we should try. With bus stuffing it should easily be possible.

 

Attached File  36_Char_201805013.zip   13.39KB   31 downloads

 

 



#9 Keatah OFFLINE  

Keatah

    Missile Commander

  • 20,567 posts

Posted Sun May 13, 2018 1:55 PM

In-cartridge instruction manuals!



#10 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Sun May 13, 2018 2:27 PM

In-cartridge instruction manuals!

Maybe... as it is there are essentially two kernels. Currently to get the perfect alignment you have to use the 'B' kernel which has all immediate loads (at 275 bytes per row!). However the 'A' kernel can still be done using the original 'A' kernel which loaded from zero page ram. That would allow good byte savings. The 'A' kernel also uses 5 bytes less of zero page ram.

 

So yeah it could be done, but to get several lines it will cost a lot of rom. Still games are getting larger all of the time so maybe this really isn't a barrier. Overall you could still just use CDF or DPC+ and do it without wasting gobs of rom.



#11 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Mon May 14, 2018 8:59 PM

In-cartridge instruction manuals!

I made an instruction screen demo. I found I could get 13 rows comfortably in for NTSC. Hardware assistance would allow many more.

 

Attached File  36_Character_Demo_Instructions.zip   117.62KB   28 downloads



#12 enthusi OFFLINE  

enthusi

    Moonsweeper

  • 395 posts
  • Location:Potsdam, Germany

Posted Tue May 15, 2018 7:52 AM

I am really no big fan of flicker but for something 'outside the game' such as this, it can be quite cool.



#13 Keatah OFFLINE  

Keatah

    Missile Commander

  • 20,567 posts

Posted Tue May 15, 2018 8:15 AM

BBS'es and terminal programs.



#14 Mr SQL OFFLINE  

Mr SQL

    Stargunner

  • 1,889 posts

Posted Tue May 15, 2018 9:23 AM

I am really no big fan of flicker but for something 'outside the game' such as this, it can be quite cool.

 

Lightening the blue background with the controller makes the 30 Hz full screen flicker appear to vanish completely in emulation and on CRT.



#15 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 688 posts
  • Location:Orlando, FL US

Posted Tue May 15, 2018 11:01 AM

Here is a perfectly aligned 36 character demo that is a mock-up for CDF or DPC+. After I made it I realized the irony that I am actually doing the display on stock hardware and that it is perfectly aligned. It uses immediate loads to mock the 2 cycle fast fetch loads that CDF and DPC+ do. This is not the droid I was looking for, but at least it proves the 2600 is capable of doing a perfectly aligned 36 character display on stock hardware. I do still believe the perfectly aligned 36 character routine in which the data can be loaded from zero page ram is accessible using stock hardware. That is the next bar to reach. Somebody will do it.

 

With CDF or DPC+ 40 characters should be the target. I don't know if we can get there, but we should try. With bus stuffing it should easily be possible.

 

attachicon.gif36_Char_201805013.zip

 

 

 

If you provide a perfectly aligned 40 character demo that is a mock-up for bus stuffing I'll implement it for the encore cart. Since you'll have to use whatever values are in A, X, and Y I think a simple vertical color bar pattern would be fine.



#16 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 688 posts
  • Location:Orlando, FL US

Posted Thu May 17, 2018 7:35 AM

Maybe the way to get to 40 is using resp0 strobe trick for P0 and putting a wide double P1 between the P0 triplets. There would be some gaps between players, but it seems feasible to have them align with the spaces between characters and use the ball and missiles to fill in any gaps that are left.

0 0 0 1 0 0 0 1 0 0 
 0 0 0 1 0 0 0 1 0 0


#17 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Sun May 20, 2018 1:50 PM

 

Maybe the way to get to 40 is using resp0 strobe trick for P0 and putting a wide double P1 between the P0 triplets. There would be some gaps between players, but it seems feasible to have them align with the spaces between characters and use the ball and missiles to fill in any gaps that are left.

0 0 0 1 0 0 0 1 0 0 
 0 0 0 1 0 0 0 1 0 0

Even though there seems to be lots of cycles with bus stuffing, I think as soon as you play with missiles it becomes tricky. I haven't looked at this yet.



#18 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Sun May 20, 2018 2:02 PM

Today I made an interlaced version of the 36 character display. :)

 

Attached File  36_Char_Interlaced_201805020.zip   8.91KB   25 downloads

 

 

This is a perfectly aligned 36 character demo running on stock hardware. It is a mock up for CDF or DPC+ which is where its usage becomes practical. The screen color is black to hide the ball and the HMOVE bars.



#19 SpiceWare OFFLINE  

SpiceWare

    Draconian

  • 12,204 posts
  • Medieval Mayhem
  • Location:Planet Houston

Posted Sun May 20, 2018 4:23 PM

Nice!  

 

Too bad about having to use the ball to hide the early GRP0 update, a 144 pixel display would have been sweet! Still, should be able to use it for a bitmap larger than 128 pixels. Will look into it when I resume work in SpiceC next month.



#20 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Sun May 20, 2018 7:52 PM

Unfortunately this kernel was never meant for a 144 bitmap. There are lots of gaps between the characters. I do have some ideas to explore for getting to a 144 bitmap or larger, but I haven't tried them yet.

 

In the meantime these character kernels are fun to do, and can make some nice text displays. :)



#21 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 688 posts
  • Location:Orlando, FL US

Posted Mon May 21, 2018 9:37 AM

Even though there seems to be lots of cycles with bus stuffing, I think as soon as you play with missiles it becomes tricky. I haven't looked at this yet.

 

Indeed, dealing with the extra copies of the missile make it difficult to leverage them. Fortunately it's manageable when using double wide spacing. Here's a prototype for a full 160x192 30hz kernel. Maybe with some more effort this could be optimized further to work without bus stuffing. When I get a chance I'll port it over to harmony and implement the actual bitmap. M1 fills in 2 gaps, and BL overwrites a single pixel where GRP0 overlaps between 2 copies. I think interlacing is going to be difficult or impossible. In order to line up everything perfectly between the alternating frames you really need to shift the frame over 24 pixels. Each half of the screen is one of the frames that would need to be flickered at 30Hz to produce the 160 pixel bitmap.

 

Attached File  fullbitmap.bin   4KB   16 downloads

fullbitmap-player-colors.png

fullbitmap-debug-colors.png

Attached File  fullbitmap.asm   2.53KB   17 downloads



#22 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Mon May 21, 2018 10:54 AM

I think that will work brilliantly. :thumbsup:

 

With interlacing, consider a multiline kernel as shifting left by 8 with an early HMOVE is always nice for hiding the comb.



#23 Omegamatrix OFFLINE  

Omegamatrix

    Quadrunner

  • Topic Starter
  • 6,186 posts
  • Location:Canada

Posted Tue May 22, 2018 11:39 PM

Zack, I wrote a testrom for your kernel. It works fine in Stella although I haven't been able to test it on real hardware yet. Well done Zack. :)

 

This test rom turns off a single bit column at a time. You can change the selected bit by using the joystick. This is not bus stuffing... just a testrom using zeropage ram.

 

 

Attached File  160_Bitmap_201805022.zip   10.85KB   19 downloads

 

 

I'm really looking forward to seeing a full bitmap image done with bus stuffing.



#24 enthusi OFFLINE  

enthusi

    Moonsweeper

  • 395 posts
  • Location:Potsdam, Germany

Posted Wed May 23, 2018 5:41 AM

A full monochromatic 160 x whatever bitmap was the obvious thing to come from bus-stuffing/ARM.

Then you can realize ANY game imaginable. Doom, Super Mario Land, Final Fantasy.

All of that has been done before on other plattforms. None of that has anything to do with the Atari2600 in my opinion.

The ARM has the power of the Nintendo DS...

I wonder why people try so hard to escape the natural limits of the system?

I am all in for optimizing code for a given original system more and more.

This trend however seems to aim at the opposite direction. Sloppy ARM code for the beautyful 2600.

I hope no one feels offended by my thoughts on this.



#25 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 688 posts
  • Location:Orlando, FL US

Posted Wed May 23, 2018 7:46 AM

A full monochromatic 160 x whatever bitmap was the obvious thing to come from bus-stuffing/ARM.

Then you can realize ANY game imaginable. Doom, Super Mario Land, Final Fantasy.

All of that has been done before on other plattforms. None of that has anything to do with the Atari2600 in my opinion.

The ARM has the power of the Nintendo DS...

I wonder why people try so hard to escape the natural limits of the system?

I am all in for optimizing code for a given original system more and more.

This trend however seems to aim at the opposite direction. Sloppy ARM code for the beautyful 2600.

I hope no one feels offended by my thoughts on this.

 

Most of the best selling homebrews have been based on some form of ARM acceleration lately. This ship has sailed.

 

That said, I think the best use of a 160x192 bitmap would be to display a logo screen for a few seconds on startup so it's obvious that the game you're playing uses modern 2600 cart tech.

 

Btw, if you are hoping not to offend, you should refrain from posting things like "Sloppy ARM code"






1 user(s) are browsing this forum

0 members, 1 guests, 0 anonymous users