Realistic pixel screens

[cold nebula]

Stuffe has talked about making a pixel screen object. Real pixel screens have "blanking periods" in which nothing is drawn and attempting to draw something might even damage the device, so computer engineers have to be careful to get the timing right.

My suggestion: have an input pin that tells the screen when to start drawing the next line and which is ignored if it's already being drawn. Those of us who care about mimicking real hardware can work out the appropriate timing ourselves. Those who don't can just tie this pin high with an On object and be done with it.

[safe tundra]

i thought that the blanking period only happened with CRT screens. Can you show info that shows that it ever applies to modern displays?

[hasty sable]

in any case, that behavior can be modelled with a CC between the input and the screen

[quasi apex]

vga uses it even though the connected display may not be a crt

[cold nebula]

http://www.tinyvga.com/vga-timing

[safe tundra]

there are other types of display interfaces - HDMI, DisplayPort, etc

[cold nebula]

Also, look up Ben Eater's 2 videos on "world's worst video card."

He outputs graphics onto an LCD screen and still has to worry about blanking periods.

[cold nebula]

What's a "CC"?

[safe tundra]

i would guess, based on what botondmester said, is that he has to deal with that 'cos of VGA

[safe tundra]

custom component

[cold nebula]

Thanks.

But no, that doesn't work because screens expect pixel data to come in at a certain rate, and if they don't get that data in time they just skip drawing some pixels. They don't wait forever.

Actually, I've heard that some LCDs can delay a short while between pixels - though not forever - if needed, so I should probably amend my request. Instead of taking a signal to draw the next line, it should be a signal to draw the next individual pixel. It won't make a difference to those who simply tie the signal high but it will give perfect control to those trying to implement realistic timing.

[inland whale]

I am pretty sure that the display that will be implemented will be directly connected to a RAM and display the raw bytes. Based on that you can create a custom component that simulates whatever "weird" behavior you want

[safe tundra]

yeah, you can have any circuit between your CPU and the screen itself - where you can implement the logic of GPU, connector, and electronics of the monitor itself

[cold nebula]

The rest I grant you, but whether we can mimic the behavior of a real pixel display depends on what features the display object has. That's why I'm making this request.

A "draw the next pixel now" pin should be trivial to implement, gives us complete control over the timing and can just be tied high for those who don't care. I'm not seeing why you're so resistant to the idea.

[inland whale]

You can trivially implement the "draw next pixel now" pin. I am resistent agains the idea because it doesn't add anything

[cold nebula]

HOW do you implement that when the display expects pixel data at a certain rate and skips pixels when it doesn't get it on time? Because if it doesn't do that then it's not really a normal pixel display.

[safe tundra]

that's just having a CC that goes over all pixel addresses of of the screen automatically, so it receives pixel data, and writes it at current address
so address is a large counter, that is controlled by a small counter to update each N ticks, and whenever you receive the pixel data, you force the address to update, and reset the smaller counter

[inland whale]

it doesn't expect pixel data at a certain rate

Where are you getting that idea?

It reads from a RAM, where you can write at whatever position and time you want

If you want, you can trivially build a wrapper on top of that that does whatever you want

[safe tundra]

no, he's saying that the "real" displays expect data at certain rate

[cold nebula]

The issue isn't WRITING to RAM, but reading from it. Your monitor - the real one you're reading this on - loads data at a fixed rate regardless of when you wrote it.

And it's not true that you can write to video memory whenever you want; in real systems the CPU is typically only allowed to write to it during the blanking periods, because the GPU needs to read from that memory during the drawing periods.

[inland whale]

Ok, but that is completly indepedent of the component

the display component is a magic display component that directly displays the RAM content, the moment you write it (or at whatever the visual refresh rate is).

On top of that, you can build proper VRAM, or a VGA like output system if you want that extra challenge. But if you don't want that, you can have it easy and don't have to worry about that

[cold nebula]

"the display component is a magic display component that directly displays the RAM content, the moment you write it"

That's how the console display works. We don't know that Stuffe will implement pixel displays in the same way.

And if he does, that's going to take a LOT of RAM. A 640x480 display is 307,200 pixels, and he'll probably use a 32-bit value for each to accomadate all three color channels. That's 1,228,800 bytes, or more than a mebibyte (1,200 kibibytes, to be exact). How big can a RAM block get in TC?

[inland whale]

Currently RAM blocks are limited quite a lot, but that can be changed

Also, a megabyte is not exactly a lot of memory...

We don't know that Stuffe will implement pixel displays in the same way.

While we can't know, I know that I am going to argue with him about this if he decides to do something else

every other possible design will be limited in it's ability and more annoying to use.

And I suggested this kind of design a few times to him, and he didn't disagree

if you would prefer a completly different design, you should make exact suggestions, not just make an assumption about how it might work and then suggest modifications to that

[cold nebula]

"Also, a megabyte is not exactly a lot of memory..."

Not in the real world, no. TC might be a different story.

"And I suggested this kind of design a few times to him, and he didn't disagree"

When he mentioned making a pixel display a couple of days ago I suggested the one-pixel-at-a-time approach, and he didn't disagree with that either.

We've BOTH been making assumptions about what he'll do. You seem to have his ear, so perhaps you should just ask him if he's made a decision on it yet.

[restive otter]

I misunderstood the title at first, i thought this was asking for a https://en.m.wikipedia.org/wiki/Racing_the_Beam like screen interface (aka ramless display). If someone is interested i could create a separate request.

i tried to explain it shortly

[cold nebula]

"aka ramless display"

That's what I was assuming the pixel display would be - like a real screen - and my request was based on that.

[restive otter]

This kind of design requires a video chip of the kind of the https://en.wikipedia.org/wiki/Television_Interface_Adaptor
This seems hard work because of timing issues and the result will be unspectacular. so this can only be a niche application or some kind of historical puzzle

[inland whale]

I do find that quite an interesting idea for a display component in the game. I am however of the opinion that the game should contain the most general display component feasiable. Based on a RAM like design, that could be implemented

Also, to note: There are quite a lot of screens, especially for micro controllers that are not RAMless/racing the beam/VGA like

small LCD displays can basically always be addressed either like the dot matrix or like a RAM

So saying "well, this kind of display is more realistic" is only half true.

[cold nebula]

"This kind of design requires a video chip"

I think you're confusing the GPU with the monitor itself.

[inland whale]

(well, not quite like the dot matrix)

[inland whale]

No I am not

You are confusing large scale monitor and small scale displays

[restive otter]

this was my message

[inland whale]

Aha yeah

Sorry

[restive otter]

what kind of design are you planning to use such a display interface ?

[inland whale]

previously WizardGuy always used quote syntax and not just quotation marks

[cold nebula]

"I am however of the opinion that the game should contain the most general display component feasiable."

I can see your point, but perhaps Stuffe could implement both if it's not too much trouble. Again, you'd have to ask him.

"There are quite a lot of screens, especially for micro controllers that are not RAMless/racing the beam/VGA like
small LCD displays"

I'm aware, but I don't believe the typical computer screen or television works that way.

"previously WizardGuy always used quote syntax and not just quotation marks"

Yes, but I noticed the entire message - including my own response - was getting marked as a quote when I did that. I'm not sure how to shut that off.

[restive otter]

In the random topics / custom level subthread i proposed a few display architecture : custom LCD panels, pure hardware display logic like https://www.youtube.com/watch?v=ppmM2zAbeEU https://github.com/baliika/fpga-tetris/blob/main/project/src/draw_frames.v

i don't remember if racing the beam / 2600 style was in the list

[cold nebula]

"what kind of design are you planning to use such a display interface ?"

I was hoping to experiment with both racing the beam and a tile-and-sprite system.

[inland whale]

Only put the > in front of the line you want to quote.

> like this

This isn't quoted

if you notice that discord automatically puts quote markings in front of your new messages, press backspace to remove it

[restive otter]

NES style tiles and sprites component will be quite expensive in terms of simulation, but if TC can run this kind of hardware that would be very interesting for retrocomputing history documentation

[cold nebula]

But that's what I was doing.

[restive otter]

Anyway for me it's interesting to recreate an environment where the hardware resources are limited to make the game challenging.

[cold nebula]

Oh, never mind. I figured it out. The first > I put down kept disappearing so I typed a second one. That must be what causes the rest of the message to get marked as a quote.

"Quote"

Testing

Hmm... No, it's still happening.

[inland whale]

You need to press backspace to end the quote

discord does the indentation automatically while you edit

[cold nebula]

"Quote"

Test #2

[restive otter]

Discord ux seems so complicated i feel they could publish an online course for it.

[cold nebula]

Ah, got it! Thanks.

[inland whale]

Is there a drawback to having very powerful components in the base game and allowing you to use (scripted) custom components to add the challenge you want?

With scripted custom components, the performance drawback should be pretty limited

[cold nebula]

"NES style tiles and sprites component will be quite expensive in terms of simulation"

That's my problem, though. All I need from TC is a display type that can mimic the behavior of a real monitor.

[restive otter]

no of course the sandbox can make complicated things possible and the puzzle levels can make simpler things harder by enforcing resource restrictions

But i would find it strange to see a custom system using say a 6502 cpu with a vga true color display. It would feel like designing a spaceship powered by a steam engine.

[cold nebula]

Let's see how fast Stuffe manages to make things with the engine rewrite.

[hasty sable]

Steam engine:

[restive otter]

I tried to give an example of technical anachronism / coal + steam used to be a real industrial powerhouse before being a software company name. cf https://en.wikipedia.org/wiki/BR_Standard_Class_9F

[sullen palm]

In my sandbox build I made a grid of the existing bitmap displays and built up circuits to drive it from a Dual RAM, either reading R,G,B tripples of bytes (3 bytes per pixel) or in an indexed-colour mode where every scanline it re-reads the palette. At the end of the screen it then flushes simultaneously as those bitmap components implement a form of double-buffering, then it either starts over or waits for a trigger. I did the index colour the way I did as reading 1 byte per pixel is much faster, but being able to change a palette index per scanline means it's easy to do Amiga-style rainbow effects.