ViTi95 wrote on 2022-08-17, 13:39:

This demo is absolutely incredible, mind blowing! I guess most of it is based on the infamous Macrocom "ASCII from Hell" idea to get that 640x200 resolution and 16 colors.

So when are we getting an ASCII from Hell renderer for FastDOOM? 😀

rasteri wrote on 2022-08-21, 16:50:

So when are we getting an ASCII from Hell renderer for FastDOOM? 😀

I think soon... I already saw there a Cacodemon 🤣

That would be really cool, I wonder if there is a way to convert a 320x200 8-bit color backbuffer to ASCII from Hell in realtime (that including dithering).

ViTi95 wrote on 2022-08-21, 21:13:

That would be really cool, I wonder if there is a way to convert a 320x200 8-bit color backbuffer to ASCII from Hell in realtime (that including dithering).

I would think it wouldn’t be that complicated since you have X combinations available at a given pixel size

You would loose the ability to have more than 2 colors per cell of pixels though

I'm not saying I'm going to do it. But if I did I'd probably just tell the Doom engine that the screen resolution is 80x100 and have a lookup table from colour index to character/attribute combination. That would be very fast, and I don't think the palette changes very often so the slowness of generating the lookup table shouldn't be a factor. I do have code (CGAArt) that would potentially give much nicer results in terms of resolution but currently it would be too slow for real time even on a modern machine. Maybe if I converted the algorithm to run in parallel on a GPU.

Well right now FastDoom supports the 160x100 CGA 16 color mode, and it's pretty fast (https://www.youtube.com/watch?v=_6Jft32G3ls). The idea is to bump the resolution to 320x200 and add color dithering, but as you said @reenigne, I guess this is way too much for older CPUs.

ViTi95 wrote on 2022-08-22, 08:23:

Well right now FastDoom supports the 160x100 CGA 16 color mode, and it's pretty fast

Hi there, when i tried fdoomc16 on newly made CGA (CGA Redux) i got a lot of "cga snow" unfortunately...
Sorry for offtopic

Spoiler

Tronix wrote on 2022-08-22, 09:35:

Hi there, when i tried fdoomc16 on newly made CGA (CGA Redux) i got a lot of "cga snow" unfortunately... Sorry for offtopic […]
Show full quote

ViTi95 wrote on 2022-08-22, 08:23:

Well right now FastDoom supports the 160x100 CGA 16 color mode, and it's pretty fast

Hi there, when i tried fdoomc16 on newly made CGA (CGA Redux) i got a lot of "cga snow" unfortunately...
Sorry for offtopic

Spoiler

photo_2022-08-21_22-17-38.jpg
P1140090.jpg

Is that snow static, or does it flicker? A small video might be nice. Does this card exhibit snow in any other apps, i.e. is it typical for this kind of CGA? I never had a CGA card, but remember that some CGA cards had snow "by default" when writing to the memory.

Also: where die you get the CGA Redux card from? Looks neat! Would love to build something like that!

root42 wrote on 2022-08-22, 12:06:

Is that snow static, or does it flicker? A small video might be nice.

Something like this: https://youtu.be/0ivcM-2TK4w

root42 wrote on 2022-08-22, 12:06:

Also: where die you get the CGA Redux card from? Looks neat! Would love to build something like that!

CGA Redux is open source project found here: https://github.com/hkzlab/CGA_Redux ,
so there are "gerber" files necessary for the production of PCB and everyone, if desired, can order their production at any PCB factory. We got together as a small Russian community and ordered around 10 PCB boards from a JLCPCB factory in China.

Neat! Thanks for the link! I will consider doing a run of PCBs over at DOSReloaded, once this year's bonuses come in. 😁 I figure the BOM is pretty expensive, as there are a LOT of TTL chips on there...

Tronix wrote on 2022-08-22, 12:22:

root42 wrote on 2022-08-22, 12:06:

Is that snow static, or does it flicker? A small video might be nice.

Something like this: https://youtu.be/0ivcM-2TK4w

Ah yes. My guess would be that the Video RAM is updated while the card is displaying. I think this is a no-no with old CGA cards, and the CGA Redux should fall into that category. My guess would be this has to be fixed on the side of Fast DOOM.

Yep, it's a known bug in FastDoom CGA text based modes with the original IBM card (and clones). I will try to fix the CGA modes that use a backbuffer, since those only update the screen when everything is rendered in RAM.

So how does 'CGA Redux' deal with this demo?

VileR wrote on 2022-08-22, 16:42:

So how does 'CGA Redux' deal with this demo?

if the question is for me, then i can't say exactly. I don't have a real 5150, I just have different kinds of XT-clones motherboards. I also do not have a real CGA monitor,so to display the image from CGA i use the MCE2VGA converter. I tried to run the demo on a "regular" XT 4.7MHz clone and it works fine in my opinion, except for the final part with image stretching and titles (greetings) - there seems to be a frame breakdown and i don’t know who is to blame - the MCE2VGA converter or CGA Redux or the motherboard. in any case, everything else in the demo works fine.
I would like to take this opportunity to say thank you for a great demo.

Spoiler

If the CGA Redux uses essentially the same circuit as the IBM CGA (particularly in regards to wait states) and has an MC6845 then the reason it fails to show the wibble and lake effects at the end is bound to be due to the motherboard - the timing needed to get all the CRTC writes in the right place is very precise and if the inner loop doesn't take exactly 304 cycles per iteration then it'll all fall apart.

A question, how many VRAM bytes are you able to update on Area 5150 per frame without having snow?

ViTi95 wrote on 2022-08-22, 19:08:

A question, how many VRAM bytes are you able to update on Area 5150 per frame without having snow?

Depends on the method, but IIRC a full vertical blanking period is enough time for some ~460 words= ~920 bytes using REP MOVSW, and with an unrolled INC DI / MOVSB sequence you can do 640 bytes (plus change... but 640 turned out to be a very convenient number). As for the horizontal blanking periods, you can't count on writing more than a byte per each (at least not reliably), but if you use all of them that's 199 more bytes per frame.

The busiest parts in the demo (in terms of VRAM writes) tend to use more specifically tailored routines like compiled sprites/compiled deltas, so the speed depends on the code itself as well as the amount of data, but that's the ballpark.

I think Plasma gets 446 words using runs of "movsw" and "add di,xx". The fade transitions can do 301 words per frame, though the limiting factor there is (by a small margin) the computations during the active display period.

Managed to get some decent 60 fps CRT footage, so here's the demo on my IBM XT with the 5153 Color Display:

https://www.youtube.com/watch?v=BdM5j96tEpE

VileR wrote on 2022-08-15, 20:30:

Jo22 wrote on 2022-08-15, 15:48:

rasteri wrote on 2022-08-15, 10:12:

I'm guessing with all the cycle-counting shenanigans involved this will never run on anything but an original 5150 😢

.. and with 8088 CPU only I guess. V20 will get no love? 😢

There are relatively few parts that are timed directly by the CPU, and I can say I personally tried to avoid instructions that would break on V20 (at least SALC, anyway). 😉 But yeah, sections like the end credits won't run correctly on anything but a 5150/55/60 (some of the better non-corner-cutting clones might get lucky). The 5140 Convertible is known to have lots of issues throughout the demo, even with the external CGA add-on.

I should also point out that only IBM CGA boards are "officially" supported... cards with subtly-different CRTC models or even with different ROM charsets won't work as intended.

Ah, I see. That's good enough to me. 🙂👍
The C64 scene has similar trouble with the different VIC-II types and different SID models.
It's very difficult to suit them all.

I'm just glad the NECs aren't totally forgotten or incompatible with the demo.
From what I remember, they were popular "upgrades" at the time.

My father replaced the 8086 in his PC directly after purchasing his PC. This was 1986 or so.
Same goes for his friends, if I remember his stories correctly.

One dude in a neighbor town, so the story goes, was busy providing V20 compatible BIOSes for a living (kind of).

So I guess the dark figure was much higher than what the books of history say.