Jump to content
IGNORED

36 Character Demo


Recommended Posts

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.

  • Like 2
Link to comment
Share on other sites

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.

 

36_Char_201805013.zip

 

 

  • Like 5
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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
Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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

 

36_Char_Interlaced_201805020.zip

 

 

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.

  • Like 5
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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.

 

fullbitmap.bin

post-40226-0-16269100-1526916923_thumb.png

post-40226-0-00755100-1526916932_thumb.png

fullbitmap.asm

  • Like 3
Link to comment
Share on other sites

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.

 

 

160_Bitmap_201805022.zip

 

 

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

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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"

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   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...