r/bbs • u/ten-oh-four • 8d ago
Any DOS ansi.sys alternative that can parse WWIV heart color codes?
I want to see if I can set up the game "Doom of Drenzilor" on a non-WWIV BBS. I have the game loading and appearing to work but the WWIV heart color codes are not being parsed by dosemu2 or by ansi.sys. Does anyone know of a DOS TSR that can parse the heart codes so that I can run this game?
Thanks!
edit - I got the game to run and the output to look correct. It wasn't an issue of the WWIV heart color codes, it was actually that I needed to manually run a TSR to render ANSI colors. I used nnansi - http://www.kegel.com/nansi/
However I can't seem to get dosemu2 virtual serial port redirection to work with this game. I can run it in 'local' mode but cannot seem to get it to run like a true door. This isn't a huge deal, but I'd really prefer to obfuscate all the dosemu2 startup text at the beginning and run it like an actual door.
The other problem is that the game runs way too fast. On screen text can move too quickly. Not sure how to deal with this one. Anyone have any ideas?
3
u/dperry324 dev / sysop 8d ago
I talked to Elihu about the source code for Doom but he no longer had it. But he was able to give me pointers on how to code my own similar game.
Too bad the current incarnation of wwiv can't parse those codes for you.
2
u/ten-oh-four 8d ago
Ah man that's a bummer. I'd love to resurrect old games. I've heard of this one a number of times so it must be pretty neat.
1
2
u/digitlman 8d ago
The WWIV codes expand to ANSI just fine under Synchronet (and I would expect them to under WWIV too, at least on Windows), but then the game promptly crashes (Runtime error 003). Not sure if that helps ya. :-)
3
u/ten-oh-four 8d ago
Oh neat! Ok. So maybe I just need to setup Synchronet as a game server for my doors :P that may solve a lot of problems honestly.
If you're inclined to try getting this to work, my instructions here are pretty basic but they should at least get things functioning - https://old.reddit.com/r/bbs/comments/1jki7x3/any_dos_ansisys_alternative_that_can_parse_wwiv/mjwerie/
2
u/digitlman 8d ago
Here's how I set it up in Synchronet for Windows:
Name doom of drezilor
Internal Code DOOMOFD
Start-up Directory ..\xtrn\doom
Command Line doom %f
I/O Method Standard, WWIV Color, No Echo
Native Executable No
Use Shell or New Context No
BBS Drop File Type CHAIN.TXT.., but yeah, it crashes. Maybe if you get it working (without crashing) provide those instructions. :-)
1
u/shurato99 sysop 8d ago
the same results with e l e BBs. I used n e t f o s s to parse the heart codes and door Master to create the chain.txt file. I still get an error 003. I think it might need to be in a specific directory.
2
u/shurato99 sysop 8d ago
Got it working by running it from the wwiv directory in the root directory.
1
u/dperry324 dev / sysop 8d ago
Does anyone know of another rogue door? This can't be the only one.
1
u/shurato99 sysop 8d ago
Tunnels and tombs. Or is it tombs and tunnels? I run that as well and there is a key generator available.
1
u/CueTheCannedLaughter 8d ago
Runtime error 003
There are two reasons the game is throwing this error. First, the installation instructions for the door are incomplete and/or faulty. Copy the DOOM.EXE file to wherever you would like to install the game. From that directory, create a sub-directory called DOOM. In that sub-directory copy the files INTRO.TXT, DOOMHELP.TXT, DOOMSPEL.TXT, and DOOMMONS.DAT. The CHAIN.TXT file from the BBS needs to be copied into the same directory as DOOM.EXE. So the resulting tree would be:
DOOM.EXE
CHAIN.TXT
DOOM\INTRO.TXT
DOOM\DOOMHELP.TXT
DOOM\DOOMSPEL.TXT
DOOM\DOOMMONS.DAT
Second, the door opens the WWIV log file even though it doesn't appear to actually write anything there. It gets the path and filename from CHAIN.TXT by concatenating line 17 (GFILES directory, must have trailing backslash) and line 19 (current logfile name). If the GFILES directory doesn't exist or the log filename isn't valid, the game will throw a Runtime error 003 when it tries to open it. If the BBS software you're using can't change this line then you'll need to get a dropfile utility or line-oriented text utility to change the line before DOOM.EXE gets run.
Then you get to find the rest of the errors in the game.
1
u/ten-oh-four 8d ago
How did you figure this out?
Thanks btw, this is great info.
1
u/CueTheCannedLaughter 7d ago
With the looking and the detecting and the observing all while all day long watching helicopters and tomato sauce.
1
1
u/RolandMT32 sysop 8d ago
What do you mean by "ansi.sys alternative"? I doubt ansi.sys could parse those, as those seem WWIV-specific.. I thought ansi.sys dealt purely with ANSI codes.
5
u/ten-oh-four 8d ago
Yeah, there were third party TSRs written ages ago for dos as alternatives to ansi.sys that had some variations of the traditional ansi.sys. For example I believe there was one that could translate pcboard color codes on the fly
5
0
u/CueTheCannedLaughter 8d ago
This game isn't using heart codes. It's writing ANSI. So when asking about "heart codes," are you asking about lack of redirection or about unparsed ANSI sequences? Or neither?
1
u/ten-oh-four 8d ago
Interesting, you're right! For some reason it looks like it doesn't play nicely with dosemu2, the display is screwed up. That's pretty unfortunate as it would be cool to host the game but I don't think that's happening :(
1
u/CueTheCannedLaughter 7d ago
It sound like you have the display issue resolved by installing NANSI, but there are two things remaining.
- Text too fast issue
This I am not sure is resolvable using DOSEmu2. It's been over a year since I've fired up either DOSEmu so I may be remembering this wrong... but I don't believe the virtual serial port is throttled. Meaning the port can't be set at a certain bps rate and have data sent through it only at that limited rate. This is something which would be needed to limit the text rate.
i/o redirection isn't working with the virtual com port. I have to run it in 'local' mode which shows all the DOS startup stuff. I'd rather have it run through the virtual com port as expected...any ideas here? None of my other DOS doors have this problem.
This door (and some other WWIV doors) are very different than what you are probably accustomed to working with. A normal door takes over the task of sending data both to the local screen and the remote user. An older style WWIV door does not. These older doors depend on WWIV to set up the system so the screen output is displayed both locally and remotely and the input is set up the same way. You're getting DOSEmu to do more or less the same thing with the local mode setup.
One of the big problems with this is 'carrier detection.' If the user disconnects, this method doesn't do anything to shut down the program. Normally doors will additionally have an input timeout and this will cause the program to exit eventually. This particular door doesn't, it's just going to sit there forever until you manually intervene.
A fix for both of these issues is a program called Doorway. It takes over the task of doing the I/O redirection which WWIV would normally be doing AND it will kill the door if the user disconnects. Download version 2.31 and look at the examples.
One other thing it could be used for is throttling the text speed. Normally the serial port could be forced at a lower rate (9600 or so) and the user would only receive the text at that speed. But this is what I don't think DOSEmu is capable of doing.
1
u/ten-oh-four 7d ago
Awesome explanation, and thanks for the recommendation. I'm going to have a look and see if this solves the issues. I appreciate it.
1
u/ten-oh-four 6d ago
I'm this close to having this working but something strange is happening. The screen clears are not taking place in the game as expected. The door launches and I can see all the original background text of the dosemu startup, and then when the screen is supposed to clear upon the user D)escending to the dungeon, instead it is drawing the dungeon directly on top of the original screen menu text. In other words, no cls's are working.
1
u/CueTheCannedLaughter 6d ago
Did you disable the redirection in DOSEmu? Seeing the existing screen contents from before Doorway was loaded is a little surprising even if the screen didn't clear properly.
Turn off video hardware access in your ANSI driver. It's usually mentioned as direct mode or fast mode in documentation. Or grab this one and load it with:
ANSI.COM SLOW ON POFF KOFF
1
u/ten-oh-four 5d ago
Yeah - I set it up with com1 virtual like other DOS doors. It's pretty strange the way it's behaving. I may just have to record a video and upload it somewhere, it's not easy to describe.
But the Doorway intro screen loads just fine, it's the first thing a user sees. Then when Doorway hands over control to doom.exe, suddenly you see the DOS boot messages appear and the game text appear right on top of it. Following that, screen clears don't work.
I can only get this game to output any text at all doing this if I use nnansi (linked in an earlier comment on this topic but can repaste if you're interested). I ran it in 'slow' mode but it hasn't made a difference. Bummer.
Thanks for your help btw.
1
u/CueTheCannedLaughter 5d ago
In trying to reproduce your issue exactly I am having nothing but problems with NNANSI. There are two ways I would suggest to proceed:
Go back to your previous configuration when you were doing the local direction. Make sure the display is correct. Then turn the local redirection back off, change back to the Doorway configuration, and add a "/V:D" parameter to Doorway. This should work but it will be a little choppy and clunky.
Switch to an ANSI driver other than NNANSI or NANSI. The ANSI driver I linked above is known to work perfectly with Doorway. If you're not using PCBOARD.SYS or DOOR.SYS to pass parameters, make sure you're passing "/G:ON" to Doorway.
3
u/shurato99 sysop 8d ago
As far as I know, the only alternative is under Windows 32 using netfoss. In IO mode. I don't think Linux can help you here.