Peter, ¿Can you access the configuration screen after pressing F3? "More power to whoever wants to do this. Let's help them instead of explaining why it is useless." +1
Gus El vie., 3 de jul. de 2020 a la(s) 10:24, Johnny Billquist (b...@softjar.se) escribió: > On 2020-07-03 14:54, Lars Brinkhoff wrote: > > Johnny Billquist wrote: > >>> Oh, and just for the people who don't want to read a lot of > >>> documentation, the smooth scrolling is essentially done by the > >>> terminal by changing where the source of the video signal generation > >>> picks up font information [...] > >>> I hope that made sense... :-) > > > > Thanks, I think it does. > > > > Emulation at this level of detail really isn't that uncommon now. > > I can't say that I've seen much of it anywhere. The VT100 also have a > lookup table for each line, so that scrolling can be done fast, but > which also means that the video generation needs to also go through that > table. While obviously you can always emulate anything, the emulating of > detail down to analog signals is not something you do that often, unless > there is additional reasons to. One reason being that this starts > becoming a performance problem. Many analog simlulations/emulations are > not done in realtime because of that. > > But if we want to emulate a terminal, I would say that realtime > emulation of the hardware is a must. > > And it's easy to just do it partially. You do have the video memory, and > for most purposes that would be good enough for the emulation to work > satisfactory, a thing like the smooth scrolling means you no longer can > stop at the abstraction of the video memory... > > >> And to take this one step further. Emulation of this then means you > >> need to start emulation the video signal generation. And that in turn > >> means you are going to do emulation of the CRT phosphor. > > > > I have no idea how MAME works, but SIMH does that for vector displays. > > Well, MAME also do vector displays. Asteroids being the classical example. > > > The current implemenation may not be suitable for raster displays, but > > it wouldn't be a huge step to add this. > > At some level this is obviously rather trivial. We are after all simply > talking about generation of a signal based on the scanning of memory, > and a bit of logic to do the sweeps and sync. An interesting question > becomes at what speed it can be done. Vector displays have a limit on > the number of vectors that can be displayed without flicker, and for the > old machines, that was not too great to start with, so simulations can > certainly deal with it, and can even get away with some cheating to make > it work even when pressed. After all, since you're also faking the > phosphor decay, it can be varied as needed. With a raster display > though, you need to be doing all the lines all the time, at an > acceptable rate, and deal with the additional hardware logic of the CRT. > > Again, definitely not impossible. But I'm curious what the speed would > look like, and I cannot remember seeing anyone who have already done it. > > Johnny > > -- > Johnny Billquist || "I'm on a bus > || on a psychedelic trip > email: b...@softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol > _______________________________________________ > Simh mailing list > Simh@trailing-edge.com > http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
