Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
rr(R)

Homepage E-mail

Berlin, Germany,
02.11.2018, 22:27
 

Game Engine Black Books and Code Reviews by Fabien Sanglard (Announce)

From 2009 to 2013 Fabien posted code reviews about Quake, Wolfenstein 3D, Doom, Quake 2, Another World, Doom 3, Quake 3, Duke Nukem 3D, Prince Of Persia (Apple II), and Future Crew's Second Reality demo to http://fabiensanglard.net/.

Then in 2017 after 3 years of work he published his book: Game Engine Black Book: Wolfenstein 3D.

In December (?) 2018 Fabien will publish his "Game Engine Black Book: DOOM". Proofing was also done by John Carmack. (Yes, the real one from ID.)

You may follow Fabien on Twitter.

rr(R)

Homepage E-mail

Berlin, Germany,
12.06.2019, 21:38

@ rr
 

Game Engine Black Books and Code Reviews by Fabien Sanglard

Books DOOM and WOLF are freely available ("Gift what you want") in PDF format from http://fabiensanglard.net/gebb/.

Rugxulo(R)

Homepage

Usono,
14.06.2019, 03:29

@ rr
 

Game Engine Black Books and Code Reviews by Fabien Sanglard

> Books DOOM and WOLF are freely available ("Gift what you want") in PDF
> format from http://fabiensanglard.net/gebb/.

I've briefly seen his site once or twice, don't remember when. Very smart guy, very interesting. It's good to see "classic" software getting appreciation.

But one quote he shared (which presumably he disagrees with) is from Patterson and Hennessy: "The x86 is an architecture that is difficult to explain and impossible to love."

"Impossible to love"?? This kind of attitude I don't understand. Certainly with the right memory model (tiny or small), it's easy enough. Certainly with the right tools (Turbo Pascal or QBASIC or A86/D86), you can do a lot of cool things. Make it work! It's one thing if you don't have time, energy, skill, or motivation. But otherwise it irks me when people seemingly refuse to make something work because of flawed ideological or purist reasoning. But hey, I have to be sympathetic, I love DOS (FreeDOS turns 25).

I'm not denying flaws or difficulties. Those two men were RISC pioneers (and 2017 Turing Award winners), influencing many others (Knuth, Wirth), and RISC-V is very popular and gaining lots of ground these days. Ultra-modern AMD64-capable machines are certainly too complex (AVX-512? Ugh!). Even I have to admit that legacy compatibility can sometimes be too much work for too little gain.

BTW, our beloved freeware Turbo Pascal 5.5 just turned 30 last month. And the 8086 turned 40 last year. I recently found a cool game called Bloxinies (with TP source).

I also recently updated my sed scripts / .BATs for PSR Invaders (assembly, no longer tied only to MASM/TASM). It's simple 8086 code, tiny model, VGA. Honestly, I want to ultimately rewrite it with TP for (also) CGA. And later I want to port minised to TP. Should be easy (famous last words)!

rr(R)

Homepage E-mail

Berlin, Germany,
16.06.2019, 17:31

@ Rugxulo
 

Game Engine Black Books and Code Reviews by Fabien Sanglard

> BTW, our beloved freeware
> Turbo Pascal 5.5 just
> turned 30 last month. And the
> 8086 turned 40 last
> year. I recently found a cool game called
> Bloxinies (with TP
> source).

1) I would still like to see FOSS version of Turbo Pascal. Or something compatible, that takes less then 1 MB on disk.
2) There also exists https://thandor.net/article/37]https://thandor.net/article/37.

> I also recently updated my sed scripts / .BATs for
> PSR
> Invaders (assembly, no longer tied only to MASM/TASM). It's simple
> 8086 code, tiny model, VGA. Honestly, I want to ultimately rewrite it with
> TP for (also) CGA. And later I want to port
> minised to TP. Should
> be easy (famous last words)!

Why TP, when it already exists written in another language?

Rugxulo(R)

Homepage

Usono,
19.06.2019, 01:14

@ rr
 

Game Engine Black Books and Code Reviews by Fabien Sanglard

> 1) I would still like to see FOSS version of Turbo Pascal. Or something
> compatible, that takes less then 1 MB on disk.

Be careful! You might make a wild MarcoV appear! :-P :-D

What exactly do you miss that you can't find in existing solutions? I somewhat know what you mean, but then again, we already have dozens of tools (of varying quality). TP is good and unique but not that unique or irreplaceable!

Small compilers? SmallerC! Or various others: XDP, XPL0, Context/DOS, FASMD (if you direly miss TP's IDE), my EZGCC2 (one floppy, 7z-compressed), Persistent S-algol (uses old A86 3.x), etc. etc. etc.

> 2) There also exists Bloxinies II.

Yes, which is also cool but different (VGA). I miss the idea of supporting various hardware for extreme compatibility.

> > I want to port minised to TP. Should be easy (famous last words)!
>
> Why TP, when it already exists written in another language?

I think it would be an interesting comparison. But I admit there is no super-obvious advantage. Still, who knows if it would be easier to speed up or fix bugs.

Rugxulo(R)

Homepage

Usono,
19.06.2019, 01:23

@ Rugxulo
 

converting minised to TP or asm

Sorry for polluting your announcement!

> > > I want to port
> minised to TP. Should
> be easy (famous last words)!
> >
> > Why TP, when it already exists written in another language?
>
> I think it would be an interesting comparison. But I admit there is no
> super-obvious advantage. Still, who knows if it would be easier to speed up
> or fix bugs.

I'd also be interested in converting it to assembly. (You know, TP was allegedly written in asm, which is why it's so small.) I always had the gut feeling that most C programs were horribly bloated, roughly 10x more than they should be. Some of that is unavoidable, and I know it doesn't usually matter, but it still feels a bit sloppy. So I blindly guess that an asm-written minised could optimally be 4 or 8 kb (uncompressed). Of course, TP has a smartlinker, so it matters less there if written in Pascal. I do prefer TP over asm these days. I don't know, it's just something I wonder about. But there are no quick fixes in life.

rr(R)

Homepage E-mail

Berlin, Germany,
21.06.2019, 20:44

@ Rugxulo
 

converting minised to TP or asm

> Sorry for polluting your announcement!

We are both free to start a new thread. ;-)

> I'd also be interested in converting it to assembly. (You know, TP was
> allegedly written in asm, which is why it's so small.) I always had the gut
> feeling that most C programs were horribly bloated, roughly 10x more than
> they should be. Some of that is unavoidable, and I know it doesn't
> usually matter, but it still feels a bit sloppy. So I blindly guess
> that an asm-written minised could optimally be 4 or 8 kb (uncompressed). Of
> course, TP has a smartlinker, so it matters less there if written in
> Pascal. I do prefer TP over asm these days. I don't know, it's just
> something I wonder about. But there are no quick fixes in life.

That reminds me about all the unfinished things on my laptop. :-|

Rugxulo(R)

Homepage

Usono,
20.07.2019, 18:00

@ Rugxulo
 

converting minised to TP or asm

> > > > I want to port minised to TP. Should be easy (famous last words)!
> > >
> > > Why TP, when it already exists written in another language?
> >
> > I think it would be an interesting comparison. But I admit there is no
> > super-obvious advantage. Still, who knows if it would be easier to speed
> > up or fix bugs.
>
> I'd also be interested in converting it to assembly. I always had the gut
> feeling that most C programs were horribly bloated, roughly 10x more than
> they should be. So I blindly guess that an asm-written minised could
> optimally be 4 or 8 kb (uncompressed). Of course, TP has a smartlinker,
> so it matters less there if written in Pascal. I do prefer TP over asm
> these days.

Classic J&W Pascal had limited string ("packed array [1..n] of char") support. I think UCSD Pascal was the inspiration for TP's "string" type. It feels almost like BASIC (no annoying bugs like in C where arrays decay into pointers/addresses). In fact, QBASIC or REXX would also be good tools for this kind of problem. (I'd already rewritten my A86 sed script into BAS, TP, C, and AWK, for comparison.)

So I finally rewrote my latest simplified FASM sed script into TP. I have a feeling that Prof. Wirth or Prof. Kernighan would call it too ad hoc. It should be simpler, more modular, more generalized! But at least it works and doesn't depend upon sed. With TP 5.5, it's only 5 kb (or 3 kb UPX'd). Not too shabby! Still, what little you save in size also means reduced functionality. Sed is better than an ad hoc, one-time, "black box" (opaque) solution.

Sets can be useful: "ch in ['a'..'z','A'..'Z','0'..'9']" = "[a-zA-Z0-9]". Although it's a size penalty to use that in TP when you don't truly need it. A few simple comparisons (like C's isalnum() function) here would have sufficed instead. So actually it was 5.5 kb until I avoided sets, then it's only 5 kb. Almost pointless to worry about such small savings, but I truly didn't need all the extra set functionality, so it should be avoided (for this one compiler).

Also, Modula-2 and Oberon are much more limited with their SETs/BITSETs. Basically, SET there is just a (byte-ending neutral??) abstraction for bitwise operations only for word-sized data (for 32-bit INTEGER, e.g. MIN(SET)=0 and MAX(SET)=31). I think J&W Pascal tried to support "set of char" (basically "array [0..255] of boolean"), but the ISO standard didn't demand that, sadly. This was one of BWK's complaints, that sets were too weak, but obviously it can be worked around or avoided. It wasn't necessarily meant to handle literally every scenario, just some limited uses.

I think C was loosely inspired by SNOBOL with such functions like strcspn() ("find first char in s1 that matches any char in set"), etc. (Icon is also an interesting successor to SNOBOL, but I'm not truly familiar with either one.)

I also wonder about Forth. I never truly learned it, plus I think it lacks some advantages of modular Wirth languages. But it's still good and has its own advantages (in small size, simplicity, portability, dynamicity = run-time vs. compile-time, etc). You know, interpreters don't have to be huge (sed isn't) for limited functionality. It just takes some TLC, some elbow grease, to finesse and whittle down everything to a reasonable subset.

Whatever, just something I'm thinking about. :lookaround:

rr(R)

Homepage E-mail

Berlin, Germany,
21.07.2019, 20:38

@ Rugxulo
 

converting minised to TP or asm

Please start a new thread for further notes. Thanks.

rr(R)

Homepage E-mail

Berlin, Germany,
21.06.2019, 20:32

@ Rugxulo
 

Game Engine Black Books and Code Reviews by Fabien Sanglard

> What exactly do you miss that you can't find in existing solutions? I
> somewhat know what you mean, but then again, we already have dozens of
> tools (of varying quality). TP is good and unique but not that
> unique or irreplaceable!

That's easy:
1) TP6+ compatible (inline assembler),
2) Self-hosting,
3) Less than 1 Mbyte,
4) FOSS.

All in one product!

Rugxulo(R)

Homepage

Usono,
25.06.2019, 07:31

@ rr
 

Turbo Pascal vs. other compilers/dialects (esp. Wirth-ian)

> > What exactly do you miss that you can't find in existing solutions? I
> > somewhat know what you mean, but then again, we already have dozens of
> > tools (of varying quality). TP is good and unique but not that
> > unique or irreplaceable!
>
> That's easy:
> 1) TP6+ compatible (inline assembler),
> 2) Self-hosting,
> 3) Less than 1 Mbyte,
> 4) FOSS.
>
> All in one product!

I definitely sympathize, obviously, but I think nostalgia is less crucial than something you can actively use. From an architectural standpoint, considering how the BIOS/CSM is going away for good, how IA-32 is basically dead (see latest Ubuntu news, among others), how AMD64 hates 16-bit code, you'll be stuck to a VM, which sometimes won't work as well as you'd like. Hey, I like 8086 and DOS, but perhaps sticking to that exclusively for the future isn't wise.

MarcoV would clearly say "Just use FPC, it's more portable, more architectures, not limited only to mode TP, and (since it's FOSS and self-hosted) can be slimmed/modified if needed." You might even be able to compress it (with various tools) if 1 MB was truly your goal (for whatever unknown reason). But you knew that.

Dialectically speaking, there's a lot of similar toolsets. For classic Pascal (ISO 7185), you have P5 and p5c. GPC is effectively inactive, so there aren't many other Extended Pascal (ISO 10206) options, but sources are still available. I think Pat Terry long ago ported Hans-Peter Mossenbock's Coco/R parser to Turbo Pascal.

Wirth added SYSTEM to Modula-2, so inline assembly wasn't needed as badly. He prefers Oberon since forever anyways. I think he went out of his way to avoid literally any assembly in his latest works, relegating the minor need for system-specific stuff to the SYSTEM pseudo-module. His preferred dialect is Oberon-07, and his Compiler Construction and Project Oberon online projects/ebooks (BSD-licensed) are self-hosted and fit in 1 MB (of RAM) on a Xilinx Spartan FPGA or whatever. Not quite what you wanted but somewhat similar. (I think GForth had a Gray parser for Oberon, too.)

Turbo Pascal borrowed a lot of stuff from Modula-2 anyways (units vs. modules, close enough), maybe even from Oberon. (The OOP stuff is called "type extension" in Oberon.) Compared to raw assembly (and we have many self-hosted assemblers), Pascal is probably easier for units, strings, and dynamic heap allocation but otherwise not groundbreaking. I think Mossenboch's Oberon-2 book is freeware nowadays, not to mention Wirth's PIO (Programming in Oberon) instead of older (famous) PIM[234]. Although there are many Oberon dialects (Component Pascal [sic], Active Oberon, Zonnon).

Oh, even Excelsior XDS Modula-2/Oberon-2 compiler (which officially is supported by Japheth's HX) has now been open-sourced (Apache 2.0)! Although I'm still wondering if GM2 will ever be upstreamed (probably!) or work with DJGPP. (Bah, we still need some work towards FPC's Go32v2 and i8086-msdos.)

I know none of this is a quick fix or perfect solution, but similar things do exist and are out there in the wild. It wouldn't be impossible to recreate TP (or similar language or functionality) for DOS. Even MarcoV I think normally used to prefer Modula-2 over TP, but nowadays he's all in for Delphi (which is quite advanced, albeit very complicated after 20+ years). Even XPL0 was loosely based upon Wirth's old Pascal-based PL/0 (from A+D=P).

Sorry for the ramble. I just don't know why it's so hard to make a useful, simple, portable, standard compiler (that is easy to rebuild!).

Rugxulo(R)

Homepage

Usono,
20.07.2019, 17:10
(edited by Rugxulo, 20.07.2019, 18:11)

@ Rugxulo
 

small DOS (Pascal-y) compilers, A86 3.x, ZDIR

> ... Persistent S-algol (uses old A86 3.x) ...

While I did download that years ago, I've never tried this compiler before, and I'm not sure it's even complete or workable. At least, a quick look didn't see any obvious way to use it properly. :confused: It's quite a mess. It's dated from 2001 (by Vector Pascal dude), but some copyrights are 1986 and 1989. Part of it was apparently written in Turbo Pascal, but it must also use (or have used) old A86 3.12 (circa 1988). Meh.

Since you mentioned ZDIR, I did track down A86 3.22 (circa 1990). I guess you've seen my very small, simple ZDIR patch (so you can now use latest A86 4.05 circa 2000). All that was needed was to add "byte" override to those four errors. For laughs, I did write a separate (unpublished) script for PSR Invaders targeting 3.22. It's apparently a much more limited assembler, though, so I don't recommend using it if you have a choice. 3.12 is actually even more limited! Just to state the obvious, I could write a generic script targeting all such A86 versions or a more elegant, simpler script only targeting latest 4.05. It's not that bad, but still, it feels strange worrying about something no one will literally ever use (hopefully). Hey, I'm sympathetic, but I don't know of any concrete reason to ever use A86 3.x anymore! The 4.x series (roughly) began in 1994, so I understand ZDIR was probably written before that.

Oh, BTW, while I've not been in contact with him, ZDIR did update his Git in February with (incomplete?) sources to ZDIRCFG (TASM/TLINK, apparently). I've not studied it closely, but it feels overkill just to have a menu-based config program when all you need is to (probably) edit a few hex bytes (via debug script??).

rr(R)

Homepage E-mail

Berlin, Germany,
21.07.2019, 20:38

@ Rugxulo
 

small DOS (Pascal-y) compilers, A86 3.x, ZDIR

Please start a new thread for further notes. Thanks.

Back to index page
Thread view  Board view
15892 Postings in 1470 Threads, 269 registered users, 106 users online (0 registered, 106 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum