Jump to content
IGNORED

PlusCart + TJ's 32-char txt + new font...


Andrew Davie

Recommended Posts

The 32 line text technology is originally by @Thomas Jentzsch

This screenshot is from the PlusCart by @Al_Nafuur on the prototype I'm running...

with my very own 3-pixel-wide Upper/Lowercase font for the actual text.

It looks remarkably good on my TV - no flicker at all.

One of those things "if I could change something to improve this, what would it be?"... "nothing. It's perfect".

This is technology that's just begging to be taken further...

 

32.thumb.jpg.5ce0fb1545959327b465c9edc82c78f0.jpg

I can see a text adventure in my near future...

Can you believe that font is just 3 pixels wide?!  Can you believe the above screenshot is from a '2600?

Unlikely, but here we have it!

 

  • Like 10
Link to comment
Share on other sites

Here's the topic from 2011 where the 32 character text display was developed on the 2600.  @solidcorp came up with the initial display, though it had some player alignment issues in a few locations that causes letters to be too far apart or too close together:

 

Text32.png

 

Then @eshu came up with a version without alignment issues for text:

32charnew.bin.png

 

though it had a player alignment issue on the right side that prevented it from working as a 128 pixel display:

32charnew2.bin.png

 

The text data for those 3 players gets shifted left 1 pixel to compensate.  In 2012 I used this arrangement for the credits easter egg in Space Rocks:

spacerocks.png

 

 

In 2016 @cd-w figured out a player arrangement that allowed for 128 pixel display:

128.png

 

 

At PRGE 2017 I showed Joe DeCuir a number of things we'd been working on, such as Bus Stuffing. The 32 character display impressed him the most.

  • Like 7
Link to comment
Share on other sites

I've made an interlaced 36 character display before:

 

36_Char_Interlaced_201805020.thumb.png.98ef3acf55c27e76c4250d2f2a556759.png

 

It's okay, but was meant to be developed further into something like CDFJ, BUS, etc... because it is just using rom right now. Lots of gaps but a good display if only 3 bit wide characters are needed.

 

There are also some other 36 character displays I made in that thread, but I believe that was the only interlaced one.

 

 

ZackAttack did work out a full 160 bit display for BUS stuffing. It's not interlaced but impressive. I wrote a test rom that focuses on one bit a time, to check the timing and it worked on my system.

  • Like 5
Link to comment
Share on other sites

2 hours ago, SpiceWare said:

Then @eshu came up with a version without alignment issues for text:

32charnew.bin.png

Thanks for the summary. ?

 

The above kernel is the base of my code. The main different is the single line vertical resolution. But I still made sure that there are always two lines used per pixel (improves LCD TVs display).

  • Like 2
Link to comment
Share on other sites

3 minutes ago, Thomas Jentzsch said:

Thanks for the summary. ?

 

gern geschehen!

 

3 minutes ago, Thomas Jentzsch said:

The above kernel is the base of my code. The main different is the single line vertical resolution. But I still made sure that there are always two lines used per pixel (improves LCD TVs display).

 

It supports single line resolution, there are 128x200 bitmap examples in the Bus Stuffing Demos topic. I didn't have space for a more detailed font in Space Rocks.

 

128bus.png

Link to comment
Share on other sites

1 minute ago, SpiceWare said:

It supports single line resolution, there are 128x200 bitmap examples in the Bus Stuffing Demos topic. I didn't have space for a more detailed font in Space Rocks.

I know and I didn't want to imply anything different.

 

My kernel is using a LOT of RAM which is required by using standard 6507 assembler. I am pretty sure a CDFJ kernel can be done much more efficiently.

  • Like 1
Link to comment
Share on other sites

3 hours ago, SpiceWare said:

Here's the topic from 2011 where the 32 character text display was developed on the 2600.  @solidcorp came up with the initial display, though it had some player alignment issues in a few locations that causes letters to be too far apart or too close together:

<snip>

 

in a situation like this, does one take the names or contact information of the main contributors and include it in the comments of the kernel so that it is memorialized in the klacks?

Link to comment
Share on other sites

Just now, Thomas Jentzsch said:

You are creating it on-the-fly. So it must be RAM, no?

For the ARM it's RAM, but for the VCS ROM.
And "on-the-fly" means, that it is "assembled" to a static 28Kb ROM in the ARM RAM while the VCS is in it's waitroutine in it's own RAM.

Link to comment
Share on other sites

6 minutes ago, D Train said:

<snip>

 

in a situation like this, does one take the names or contact information of the main contributors and include it in the comments of the kernel so that it is memorialized in the klacks?

 

I try to put links in my source like this in Frantic*:

// Constants used for divide by 5 logic using Reciprocal Multiplication
// http://homepage.cs.uiowa.edu/~jones/bcd/divide.html
#define DIV_BY_5                0xCCCD
#define DIV_BY_5_SHIFT          18
#define DIV_BY_6                0xAAAB
#define DIV_BY_6_SHIFT          18

 

But I don't always think to do it.  Doesn't look like I did for Space Rocks, though I did add Eshu to the credits easter egg because I rewrote his kernel to use DPC+ data streams instead of ZP RAM.

 

 

 

Reciprocal Multiplication is a way to do hardware division on a CPU that only has supports hardware multiplication. Can read more about it here:

 

 

 

  • Like 1
Link to comment
Share on other sites

On 9/6/2020 at 4:27 PM, Thomas Jentzsch said:

klacks?

oops, it's clacks, not klacks.

 

the clacks are a system of physical semaphores used to communicate over long distances in the discworld stories by terry pratchett.

 

in the stories, a character dies and is memorialized by sending his name back and forth (eternally) along the clack lines.

 

when pratchett died in real life, people decided to memorialize him by sending his name back and forth via their webservers.

 

https://www.theguardian.com/books/shortcuts/2015/mar/17/terry-pratchetts-name-lives-on-in-the-clacks-with-hidden-web-code

 

so I was playing on that.

 

:)

Link to comment
Share on other sites

On 9/6/2020 at 1:57 PM, Omegamatrix said:

I've made an interlaced 36 character display before:

That reminds me.  On my hardware using that 36 char interlaced kernel:

 

On my 2600 four switch woody, the first two chars have artifacts consistently on both Harmony and Unocart.

 

On the 7800, it works properly intermittently, but never consistently.

IMG_20200909_215859.jpg

  • Like 1
Link to comment
Share on other sites

On 9/7/2020 at 3:16 AM, SpiceWare said:

 

In 2016 @cd-w figured out a player arrangement that allowed for 128 pixel display:

128.png

 

 

 

 

Is the above demo a bus-stuffer, ARM based, or 6507?

I ask because I'd like to explore options for a full 128 pixel display on the PlusCart without the 3-pixel limitations per character.

Edited by Andrew Davie
Link to comment
Share on other sites

7 hours ago, Andrew Davie said:

Is the above demo a bus-stuffer, ARM based, or 6507?

 

ARM based.  It's using DPC+, not BUS.

 

There's a test ROM in reply 143 with the reverse field characters, it also shows the player layout and how the ball is used to hide 1 extra copy of a player. Note 1 about having to use the PF to hide the leftmost copies of P0 is no longer valid as Stella's been updated to emulate that correctly.

 

There's source for another version in reply 169. It does not have the reverse field characters, but does have a line drawing demo that shows the full 128 pixels across.   Use Left Difficulty to switch between the two, and the Right Difficult to colorize the players and ball to easier see the layout.

 

556242238_ScreenShot2020-09-10at10_45_35AM.thumb.png.dffd2a999e5d79d2c7ec42730187ded3.png

 

1874600630_ScreenShot2020-09-10at10_45_25AM.thumb.png.92480ff045fb585752e9f8bcac1bd0a6.png

 

597361804_ScreenShot2020-09-10at10_48_26AM.thumb.png.0333145f7dd276166fc8befdf8ba455d.png

 

If the ball object is not used the display shows this:

244098911_ScreenShot2020-09-10at10_51_23AM.thumb.png.b9b92375b5ea8697ddf59fe9dbb1c6fd.png

  • Like 1
Link to comment
Share on other sites

22 hours ago, orange808 said:

That reminds me.  On my hardware using that 36 char interlaced kernel:

 

On my 2600 four switch woody, the first two chars have artifacts consistently on both Harmony and Unocart.

 

On the 7800, it works properly intermittently, but never consistently.

IMG_20200909_215859.jpg

Thank you for reporting. On my systems it tested fine, but It is doing a lot of tight timing so I'm not surprised it failed.

 

Are your consoles NTSC?

Link to comment
Share on other sites

14 minutes ago, Omegamatrix said:

Thank you for reporting. On my systems it tested fine, but It is doing a lot of tight timing so I'm not surprised it failed.

 

Are your consoles NTSC?

Yes.  NTSC.  

 

It's the first two characters and the first column of the third character that have artifacts.  So, it might still be a reliable interlaced 33 chars kernel with a small blank space on the left.  :)

Link to comment
Share on other sites

20 years ago I wold not have ever believed this was possible on a plain-vanilla '2600.

That is, it's just standard 6507 code in action drawing this screen... pretty much a 32x16 text display.

This is the amazing PlusCart menu/display system in action once again... I'm having lots of fun designing fonts.

In my first-ever real programming job, my boss had to tell me that the font was good enough, and I "really should do some other stuff".... so it's definitely in my blood. I'm fairly confident now, that a decent text-adventure would work on this system. I've been talking to a certain person...

Anyway, posting this screenshot because new font, more lines per screen.... still think it's awesome.

And fascinating the history mentioned above -- it just shows how we all build on the advances of others, and the huge advantages for us all in freely sharing our code with each other.

 

 

512.jpg.4e2b0001b8a5ef20f0913d49682a681d.jpg

 

 

 

 

  • Like 5
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...