Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #18677 > unrolled thread

z/PDOS-generic

Back to article view | Back to alt.os.development

Contents

  z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-07-18 23:07 +0800
    Re: z/PDOS-generic Grant Taylor <gtaylor@tnetconsulting.net> - 2024-07-18 22:40 -0500
      Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-07-19 18:43 +0800
        Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-19 16:18 +0000
          Re: z/PDOS-generic BGB-Alt <bohannonindustriesllc@gmail.com> - 2024-07-19 17:12 -0500
            Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-19 23:21 +0000
              Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-19 23:31 +0000
              Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-20 01:30 -0500
              Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-22 07:51 -0700
                Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-22 15:22 +0000
                  Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-22 09:07 -0700
                    Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-22 17:37 +0000
                      Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-22 18:07 +0000
                        Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-07-22 19:38 +0000
                      Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-22 11:18 -0700
                Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-22 14:16 -0500
                  Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-22 20:14 +0000
                    Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-22 18:03 -0500
                      Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2024-07-22 23:58 +0000
                        Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-07-22 23:06 -0500
                          Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-21 04:31 +0800
                            Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-08-28 02:28 -0500
                              Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-28 16:54 +0800
                                Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-28 16:58 +0800
                                Re: z/PDOS-generic BGB <cr88192@gmail.com> - 2024-08-28 18:03 -0500
                                  Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-29 11:14 +0800
                                    Re: z/PDOS-generic George Neuner <gneuner2@comcast.net> - 2024-08-30 06:49 -0400
                                      Re: z/PDOS-generic George Neuner <gneuner2@comcast.net> - 2024-08-30 10:27 -0400
                                      Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-31 10:21 +0800
                                        Re: z/PDOS-generic George Neuner <gneuner2@comcast.net> - 2024-08-31 15:30 -0400
                                      Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2024-09-03 14:27 +0000
                                  Re: z/PDOS-generic wolfgang kern <nowhere@never.at> - 2024-08-30 13:29 +0200
            Re: z/PDOS-generic Waldek Hebisch <antispam@fricas.org> - 2024-09-03 23:38 +0000
              Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-09-06 07:46 +0800
                Re: z/PDOS-generic J. Curtis <unknown@protocol.invalid> - 2024-09-06 20:08 +0100
                  Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-09-07 08:12 +0800
                    Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-01-22 17:34 +1100
          Re: z/PDOS-generic J. Curtis <unknown@protocol.invalid> - 2024-07-20 00:02 +0100
          Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-08 14:42 -0300
            Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-09 02:09 +0000
              Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-09 15:40 +0000
                Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 12:38 +0000
                  Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 14:49 +0000
                    Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 15:00 +0000
              Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-10 09:21 -0300
                Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 13:50 +0000
                  Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-10 14:10 -0300
                    Studying the system (was Re: z/PDOS-generic) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 18:29 +0000
                    Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 05:38 +1100
                      Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 19:07 +0000
                        Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 19:09 +0000
                        Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-10 13:00 -0700
                          Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 20:20 +0000
                            Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 07:59 +1100
                            Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-10 15:11 -0700
                              Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 23:11 +0000
                                Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 10:51 +1100
                                Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-11 08:37 -0700
                                  Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 17:28 +0000
                                    Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 05:40 +1100
                                    Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-11 12:41 -0700
                                      What is an operating system? (was Re: z/PDOS-generic) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 21:00 +0000
                                        Re: What is an operating system? (was Re: z/PDOS-generic) "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 17:30 +1100
                                Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2025-03-11 09:04 -0700
                        Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 08:29 +1100
              Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 05:06 +1100
                Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 19:01 +0000
                  Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 08:04 +1100
                  Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-11 08:47 +1100
              Re: z/PDOS-generic antispam@fricas.org (Waldek Hebisch) - 2025-03-11 18:15 +0000
                Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 18:29 +0000
                  Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 05:52 +1100
                  Re: z/PDOS-generic antispam@fricas.org (Waldek Hebisch) - 2025-03-11 23:05 +0000
                    Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-11 23:48 +0000
                      Re: z/PDOS-generic antispam@fricas.org (Waldek Hebisch) - 2025-03-12 02:23 +0000
                        Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-12 02:34 +0000
                          Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2025-03-12 18:41 +1100
        Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-07-19 09:35 -0700
          Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-21 04:20 +0800
            Re: z/PDOS-generic John Ames <commodorejohn@gmail.com> - 2024-08-21 09:51 -0700
              Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-22 13:24 +0800
        Re: z/PDOS-generic Grant Taylor <gtaylor@tnetconsulting.net> - 2024-07-19 19:46 -0500
          Re: z/PDOS-generic "Paul Edwards" <mutazilah@gmail.com> - 2024-08-21 04:18 +0800
      Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-08 14:41 -0300
        Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-09 01:58 +0000
          Re: z/PDOS-generic Salvador Mirzo <smirzo@example.com> - 2025-03-10 09:31 -0300
            Re: z/PDOS-generic cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-10 14:28 +0000
            Re: z/PDOS-generic scott@slp53.sl.home (Scott Lurndal) - 2025-03-10 14:46 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#18704

"BGB" <cr88192@gmail.com> wrote in message
news:v7na8l$12737$1@dont-email.me...

> But, now I am an aging millennial and have arguably not accomplished all
> that much with my life.

Didn't you email me decades ago to get some changes implemented
to PDPCLIB and you mentioned you were writing a phenomenal
number of lines of code per day? Where did all that effort go?

Regardless, what sort of thing would you consider to be
"accomplished a significant amount"? You're not going to
single-handedly reproduce Windows 11. So if that is the
bar, no-one at all has accomplished much. It's even difficult
to credit Windows itself. Who are you going to credit?
Tim Paterson? Or Bill Gates's father's (or was it his mother's?)
money?

Note that I am not dismissing Bill Gates's technical achievements
with Microsoft BASIC, but that's not Windows 11 by a very
very very long shot.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18710

On 8/20/2024 3:31 PM, Paul Edwards wrote:
> "BGB" <cr88192@gmail.com> wrote in message
> news:v7na8l$12737$1@dont-email.me...
> 
>> But, now I am an aging millennial and have arguably not accomplished all
>> that much with my life.
> 
> Didn't you email me decades ago to get some changes implemented
> to PDPCLIB and you mentioned you were writing a phenomenal
> number of lines of code per day? Where did all that effort go?
> 

FWIW:

I ended up with a 3D engine, which was around a 1 MLOC, sort of like 
Minecraft with a Doom3 style renderer. No one cared, performance wasn't 
so good (was painfully laggy), and this project fizzled.

Part of the poor performance was the use of a conservative garbage 
collector, and rampant memory leaks, ... Another part was was "Minecraft 
style terrain rendering and stencil shadows don't mix well". Though, for 
small light sources, could subset the scene geometry mostly to a 
bounding-box around the light source.

But, the sun, well, the sun was kinda evil. Did later move to 
shadow-maps for the sun though (though, IIRC, did RGB shadow maps to 
allow for colored shadows through colored glass).


Then I wrote a new 3D engine ground-up, which was smaller and had better 
performance. Few people cared, I lost motivation, and eventually it 
fizzled as well. Was roughly around 0.5 MLOC, IIRC.

It had replaced the complex dynamic lighting with the use of 
vertex-color lighting (with a single big rendering pass).


I started on my CPU ISA project, which checking, is around 2 MLOC (for 
the C parts.

It is ~ 3.8 MLOC total, if one includes a lot of ASM and C++ code; but a 
fair chunk of this is auto-generated (Verilator output, or debug ASM 
output from my compiler).

There is also around 0.8 MLOC of Verilog in my project; but this drops 
to 200 kLOC if only counting the current CPU core.




Ironically, the OS for my current ISA project has reused some parts from 
my past 3D engine projects.

In the course of all this, ended up doing roughly 3 separate 
re-implementations of the OpenGL API (the 3rd version was written to try 
to leverage special features of my ISA; though was originally written to 
assume a plain software renderer, and since implementing a ).

In my current project, I have ports of GLQuake and Quake 3 Arena working 
on it; though performance isn't good on a 50MHz CPU.


Ironically, parts of PDPCLIB still remain as a core part of the "OS", 
though I had ended up rewriting a fair chunk of it to better fit my 
use-case (the "string.c" and "math.c" stuff ended up almost entirely 
rewritten, though a fair chunk of "stdio.c" and similar remains intact). 
It was also expanded out to cover much of C99 and parts of C11 and C23.

Some wonky modifications were made to support DLLs, which ended up 
working in an unusual way in my case:
   The main binary essentially exports a COM interface to its C library;
   Most of the loaded DLLs have ended up importing this COM interface,
     which provides things like malloc/free, stdio backend stuff, ...


It also has a small makeshift GUI, though mostly just displays a shell 
window that can be used to launch programs.


Besides my own ISA, my CPU core also runs RISC-V.

There is a possible TODO effort of trying to implement the Linux syscall 
interface for RISC-V Mode, which could potentially allow me to run 
binaries letting GCC use the "native" GLIBC, which could make porting 
software to it easier (vs the hassle of getting GCC to use my own 
runtime libraries; or trying to get programs to build using my own 
compiler as a cross-compiler).


Though, I did more or less get my compiler to pretend to be GCC well 
enough that for small programs, it is possible to trick "./configure" 
scripts to use it as a cross compiler (doesn't scale very well, as apart 
from some core POSIX libraries, most anything else is absent).

Where, for my own ISA, I am using BGBCC.
   BGBCC is ~ 250 kLOC, and mostly compiles C;
     Also compiles BGBScript, which sorta resembles ActionScript;
     And, BGBScript2, which sorta resembles Java mixed with C#;
       Albeit, unlike Java and C#, it uses manual and zone allocation.
     Technically could be mixed with C, all using the same ABI;
     Also an EC++ like subset of C++.
       But, kinda moot as no "Modern C++" stuff has any hope of working.
     But, for my current uses, C is dominant.
   It is sorta wonky in that it does not use traditional object files.
     It compiles into a stack-oriented bytecode and "links" from this.
     The bytecode IR could be loosely compared with MSIL / CIL.
     ASM code is preprocessed and forwarded as text blobs.
   The backend then produces the final PE/COFF images.
     Though, this mutated some as well:
       Lacks MZ stub / header;
       PE image is typically LZ4 compressed.
         LZ4 compression makes the loading process faster.
     Resource section was replaced with a WAD2 variant.
       Made more sense to me than the original PE/COFF resource section.
       Compiler also has a built-in format converter.
         Say, to convert TGA or PNG into BMP (*1), ...

*1: General resource-section formats:
   Graphics:
     BMP, 4/8/16/24/32 bit.
       Ye Olde standard BMP.
       For 16 and 256 color, fixed palettes are used.
     BMPA, 4/8 bit with a transparent color.
       Basically standard, but with a transparent color.
       Generally, the High-Intensity Magenta is transparent.
         Or, #FF55FF (or, Color 13 in the 16-color palette)
     BMP+CRAM: 2 bpp 256-color, image encoded as 8-bit CRAM.
       Supports transparency in a limited form:
         Only 1 non-transparent color per 4x4 block,
         vs 2 colors for opaque blocks.
     QOI: An image in the QOI format (lossless)
     LCIF: Resembles a QOI/CRAM hybrid, lossy low/intermediate quality.
       Though, BMP+CRAM is faster and has lower overhead.
     UPIC: Resembles a Rice-coded JPEG
       Optimized for a small low-memory-overhead decoder.
       Lossy or Lossless, higher quality, but comparably slow.
   Audio:
     WAV, mostly PCM, A-Law, or ADPCM.


BGBCC originally started as a fork off of my BGBScript VM, which was 
used as the main scripting language in my first 3D engine.

By the 2nd 3D engine, it had partly been replaced by a VM running my 
(then) newer BGBScript2 language, with the engine written as a mix of C 
and BGBScript2.

While I could technically use BGBScript2 in my TestKern OS, it is almost 
entirely C, only really using BGBScript2 for some small test cases (it 
is technically possible to use both BS and BS2 in kernel and bare-metal 
contexts; and there is partial ISA level assistance for things like 
tagged pointers and dynamic type-checking). Where, BS2 retains (from BS, 
and its JS/AS ancestors) the ability to use optional dynamic types and 
ex-nihilo objects (also BGBCC technically allows doing so in C as well, 
with some non-standard syntax, but doing so is "kinda cursed").

Ironically, I am using a memory protection scheme in my ISA based on 
performing ACL checks on memory pages. The basic idea for this scheme 
was carried over from my original BGBScript VM (where it was applied per 
object), where the idea for the scheme was (ironically) inspired partly 
by how object security was passed off in the "Tron 2.0" game (in 
context, as a more convoluted way of passing off the use of keycards for 
doors). But, I was left thinking at the time that the idea actually 
sorta made sense. But, in its present form mostly involves applying 
filesystem-style checks to pages (the MMU remembers this, but raises an 
exception whenever it needs the OS to sort out whether a given key can 
access a given ACL).

Well, and also the use of pointers in my ISA with a 48-bit address, and 
16 bits of tag metadata in the high order bits, was also itself partly a 
carry-over from my Script VMs.



Near the end of my 2nd 3D engine (before the project fizzled out 
entirely): It also gained the ability to load BJX2 images into the 3D 
engine. In the effect, the 3D engine would itself take on a role like an 
OS, effectively running logical processes inside the VM (though, there 
wasn't really an API to glue these into the game world).

IIRC, the idea I think was to make the "game server" able to run 
programs OS style, which could then run parts of the game logic (rather 
than necessarily using my BGBSCript2 language running in a VM; 
potentially the BS2 VM code could be ported to BGBCC and run inside the 
BJX2 VM). Though, potentially, one could also make a case for using 
RISC-V ELF images. Wouldn't necessarily want to run native x86-64 code 
as it would be desirable to be able to sandbox the programs inside of a 
VM. In such a case, the idea would be that things like voxel 
manipulation or interaction with world entities could be via COM 
objects, or potentially game objects could signal events into the script 
programs.


Can note that my BJX2 project was preceded by BJX1, where BJX1 started 
out as a modified version of the Hitachi SH-4 ISA (most popularly used 
in the SEGA Dreamcast). I had revived BGBCC initially as I needed a 
compiler to target BJX1 (and SH-4). As BJX1 turned into a horrible mess 
(turned 64-bit, and fragmented into multiple variants), I eventually did 
a "partial reboot".

At the ASM level, initially BJX2 was very similar to BJX1, mostly 
carrying over the same ASM and ABI, but with minor changes (and gaining 
some features and notation inspired by the TMS320). The BJX2 ISA mutated 
over time, and has since also fragmented to some extent (and its current 
form also has some similarities to SH-5).

It has since drifted towards being more like RISC-V in some areas, 
mostly because my CPU core can now also run RISC-V code (and, if RISC-V 
needs a feature, and it is useful, may as well also have it in my own ISA).

ASM syntax/style mostly borrowed from SH-4, which seems to be in a 
similar category that also includes the likes of MSP430, M68K, PDP-11, 
and VAX. Well, as opposed to RISC-V using a more MIPS-like style.



I also don't really have a "proper" userland as of yet, more the kernel, 
shell, and most basic programs, all exist as a single binary (so, say, 
if you type "ls", the shell handles it itself; with shell instances as 
kernel mode threads).

Any "actual" programs are loaded and then spawned as a new process.

Only recently-ish added the ability to redirect IO, but still doesn't 
support piping IO between programs.
Supports basic shell-scripts, but lacks most more advanced shell 
features (non-trivial Bash scripts will not work).


There was a 3rd 3D engine of mine, mostly because my 2nd 3D engine would 
have still been too heavyweight to run on my CPU core (tried to write 
something Minecraft-like that would run in a similar memory footprint to 
Quake and was fast enough to be tolerable on a 50MHz CPU).

Between the engines:
   Chunk Size: 16x16x16 in both engines;
   Region Size: 16x16x16 in 2nd engine, 8x8x8 in 3rd.
     32x32x8 in first engine.
     Thus, in 3rd engine, each region was a 128x128x128 meter cube.
   Block Storage:
     1st engine: 8 bit index or unpacked;
     2nd engine: 4/8/12 bit index into table of blocks;
     3rd engine: 4/8 bit index into block table, or unpacked block array.
   World Size:
     1st engine: Planar
     2nd engine: 1024km (1048576 meters), world wraps on edge
     3rd engine: 64km (65536 meters), world wraps on edge
   Rendering:
     1st engine: global vertex arrays, filled from each chunk
     2nd engine: Per-chunk vertex arrays
     3rd engine: Raycast, visible blocks drawn into global vertex arrays.
   Chunk Storage:
     1st engine: RLEW (same format as used for maps in Wolf3D and ROTT)
     2nd engine: LZ77 + AdRiceSTF
     3rd engine: RP2 (similar to LZ4)
   Graphics storage:
     1st engine: JPEG (modified to support Alpha channel)
     2nd engine: BMP + BTIC4B (8x8 Color-Cell, AdRice Bitstream)
     3rd engine: DDS (DXT1)
   VFS File Storage:
     1st engine: ZIP
     2nd engine: BTPAK (Hierarchical Central Directory, Deflate)
       Large files broken up into 1MB fragments;
     3rd engine: WAD4 (Hierarchical Central Directory, RP2)
       Large files broken into 128K fragments.
   Audio:
     1st engine: WAV (PCM)
     2nd & 3rd engine: WAV (IMA ADPCM)

Both 2nd and 3rd engine used the same block-type numbers and the same 
texture atlas.

Both 2nd and 3rd engine had used mostly sprite graphics, for my first 3D 
engine, I had used 3D models (and skeletal animation), but this was a 
lot of effort.

I then noted that sprite graphics still worked well in Doom, and 
attempted to mimic the use of sprites, though generally using 4 angles 
rather than 8, as 4 was easier to draw. Also using a trick as seen in 
some old RPG's where one could pull off idle animations and walking by 
horizontally flipping the sprite on a timer.

Initial goal (before the 2nd engine effort fizzled out) was to try to 
build something like Undertale, but this was more effort, and I was 
lacking a good system for dialog and managing game-event dependency trees.

My 3rd engine never got much past "try to make something that works on 
my ISA and can fit in under 40-60MB of RAM".

One minor difference was for live entity serialization within regions, 
where my 2nd engine had mostly embedded data within ASCII strings, 
whereas the 3rd engine had used binary-serialized XML blobs (reusing the 
XML code from BGBCC, where for better or worse; BGBCC had uses XML DOM 
style ASTs; but reworked to be a lot more efficient than the original DOM).



Also, some amount of specialized image and video codecs, etc.
There is an experimental video player and Mod/S3M player, though not at 
present generalized enough to be usable as media players (would need 
some level of UI for this; thus far these load a hard-coded file and 
just play it in a loop).

And, some on/off fiddling with things like Neural Nets, etc.


Recently I wrote a tool to import UFO / GLIF fonts and convert them to 
an custom font format (mostly as the actual TTF format seemed needlessly 
complicated). This was along with the code to render this style of font. 
Unclear if it will replace the use of bitmap fonts and SDFs.

Where:
   Bitmap font:
     Specialized for specific glyph sizes;
     Looks good at that size;
     Don't really scale.
   SDF font:
     Scalable (works best for medium glyphs);
     Relatively cheap in a computational sense;
     But, relatively bulky and eat a lot of memory.
       I stored them mostly as 8bpp BMP images, 4-bit X/Y.
       Where, each 16x16 glyph page is a 256256 BMP,
   Variable / Geometric Font:
     Scalable (but works best for large glyphs);
       Attempts to draw small glyphs give poor results ATM.
       Currently need to draw at 4x final size then downsample.
     Higher per-pixel cost;
     Less memory needed to hold font;
     Can be used to generate SDF's or triangles.



For my ISA / OS project, the fonts and some other things had been 
carried over from my 3D engine projects. Well, along with a lot of the 
VFS and memory management code (wasn't too much effort to adapt my 3D 
engine VFS code to work as an OS VFS).

Main practical difference being that, for an OS VFS, it has a FAT32 
driver and similar.



But, I have slowed down in recent years I suspect.


> Regardless, what sort of thing would you consider to be
> "accomplished a significant amount"? You're not going to
> single-handedly reproduce Windows 11. So if that is the
> bar, no-one at all has accomplished much. It's even difficult
> to credit Windows itself. Who are you going to credit?
> Tim Paterson? Or Bill Gates's father's (or was it his mother's?)
> money?
> 
> Note that I am not dismissing Bill Gates's technical achievements
> with Microsoft BASIC, but that's not Windows 11 by a very
> very very long shot.
> 

Dunno...

Just is seems like a lot of other people are getting lots of 
recognition, seem to be doing well off financially, etc.

Meanwhile, I just sort of end up poking at stuff, and implementing 
stuff, and it seems like regardless of what I do, no one gives a crap, 
or like I am little better off than had I done nothing at all...



> BFN. Paul.
> 
> 

[toc] | [prev] | [next] | [standalone]

#18711

"BGB" <cr88192@gmail.com> wrote in message
news:vamjih$3d4m7$1@dont-email.me...


> Just is seems like a lot of other people are getting lots of
> recognition, seem to be doing well off financially, etc.
>
> Meanwhile, I just sort of end up poking at stuff, and implementing
> stuff, and it seems like regardless of what I do, no one gives a crap,
> or like I am little better off than had I done nothing at all...

Did you consider asking anyone at all if they were after
something?

> Where, for my own ISA, I am using BGBCC.
>    BGBCC is ~ 250 kLOC, and mostly compiles C;

We have struggled and struggled and struggled to try to get
a public domain C90 compiler written in C90 to produce 386
assembler.

There have been a large number of talented people who tried
to do this and fell flat on their face. I never even tried.

The closest we have is SubC.

Is this a market gap you are able and interested in filling?

By either modifying BGBCC (and making public domain if
it isn't already), or using your skills to put SubC over the line?

I can only guarantee that I will recognize your work if you do
this, but that's potentially better than no-one at all. Also, there
is likely to be more than just me who appreciate having a C90
compiler in the public domain.

We currently use the copyrighted GCC 3.2.3 (my modification
of it) in order to get full C90.

There are some other targets of interest besides 386, namely
370, ARM32, x64, 68000. ARM64 would be good too, but
we don't have that at all.

8086 is another target of interest. SubC is already being used
to produce a bootloader for PDOS/386, but Watcom is better
because of SubC's primitive nature.

Thanks. Paul.

[toc] | [prev] | [next] | [standalone]

#18712

Linas Vepstas was kind enough to assist in debugging
binutils i370 and now z/PDOS-generic has a GCC that
is able to do an optimized compile without crashing.

It is also able to make directories.

This is all EBCDIC.

https://pdos.org/zpg.zip

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18714

On 8/28/2024 3:54 AM, Paul Edwards wrote:
> "BGB" <cr88192@gmail.com> wrote in message
> news:vamjih$3d4m7$1@dont-email.me...
> 
> 
>> Just is seems like a lot of other people are getting lots of
>> recognition, seem to be doing well off financially, etc.
>>
>> Meanwhile, I just sort of end up poking at stuff, and implementing
>> stuff, and it seems like regardless of what I do, no one gives a crap,
>> or like I am little better off than had I done nothing at all...
> 
> Did you consider asking anyone at all if they were after
> something?
> 

I mostly just did stuff, occasionally posting about it on Usenet, 
occasionally on Twitter (now known as X...).


For my 3D engines, I posted stuff about them on YouTube; relatively 
little feedback, in the time of the first 3D engine, was mostly people 
complaining about "ugly graphics" and "looks like Minecraft" (which was 
sorta the thing).

The 2nd engine looked even more like Minecraft, apart from also taking 
minor influences from things like Undertale and Homestuck (but, 
generally, was closer to Minecraft than Undertale; apart from the use of 
billboard sprites for things like NPCs).


The 3rd engine had some particularly awful sprites, mostly because:
The 2nd engine sprites were generally fairly high res;
For the 3rd engine I just quickly drew some stuff and called it good;
But, the 3rd engine was more meant as a technical proof of concept than 
an actual game.

Arguably, I could have tried to "lean into it", maybe do characters as 
32x64 pixel art style (with nearest sampling), but didn't bother.

Terrain generation algorithms:
   1st engine had used Perlin Noise.
   2nd engine had just used X/Y/Z hashing functions and interpolation.
   3rd engine, basically same as 2nd engine.

Hash functions generally being better behaved than Perlin Noise. Though, 
some care is needed, as poor hashing may lead to obvious repeating patterns.



Eventually, I mostly gave up on gamedev, as I couldn't seem to come up 
with anything that anyone seemed to care about, and my own motivation in 
these areas had largely dried up (and most of the time, I ended up being 
more motivated to fiddle with technical stuff, than to really do much in 
artistic/creative directions; as "artistic creativity" seems to be an 
area where I am significantly lacking).


>> Where, for my own ISA, I am using BGBCC.
>>     BGBCC is ~ 250 kLOC, and mostly compiles C;
> 
> We have struggled and struggled and struggled to try to get
> a public domain C90 compiler written in C90 to produce 386
> assembler.
> 
> There have been a large number of talented people who tried
> to do this and fell flat on their face. I never even tried.
> 
> The closest we have is SubC.
> 
> Is this a market gap you are able and interested in filling?
> 
> By either modifying BGBCC (and making public domain if
> it isn't already), or using your skills to put SubC over the line?
> 

It is MIT licensed, but doesn't currently produce x86 or x86-64 (as I 
mostly just used MSVC and GCC for PC based development).

Rather, backends it currently has are:
   BJX2
   BJX1 and SH-4 (old)
   BSR1 (short lived)
     Another custom ISA, inspired by SuperH and MSP430.
Very early versions targeted x86 and x86-64.
   But, this backend was dropped long ago.
   Did briefly attempt a backend for 32-bit ARM, but this was not kept.
     This was in a different fork.
     Performance of the generated code was quite terrible.
     Didn't really seem worth the bother at the time.

Much of the current backend was initially derived from an 'FRBC' 
backend, which was an attempt to do a Dalvik style register IR.
The FRBC VM was dropped, as while fast, the VM was very bulky in terms 
of code footprint (combinatorial mess). But, at the time, wasn't a big 
step to go from a register IR to an actual CPU ISA, and (for a sensibly 
designed ISA), it is possible to emulate things at similar speeds to 
what one could get with a similar VM.

My current emulator (for BJX2) is kinda slow, but this is more because 
it is usually trying to be cycle-accurate, and as long as it is possible 
for it to be (on the PC side of things) faster than the CPU core on the 
target FPGA, this is good enough...



AFAIK, whether declaring something as public domain is legally 
recognized depends on jurisdiction. I think this is why CC0 exists.

Personally, I am not all that likely to bother with going after anyone 
who breaks the terms of the MIT license, as it is pretty close to "do 
whatever", similar for 3 clause BSD.

It is also more C95 style, making significant use of // comments and 
"long long" and similar, more or less the C dialect that MSVC supported 
until around 2015 or so (when they started adding C99 stuff).



I had at one point wanted to try to make a smaller / lighter weight C 
compiler, but this effort mostly fizzled out (when it started to become 
obvious that I wasn't going to be able to pull off a usable C compiler 
in less LOC than the Doom engine, which was part of the original design 
goal).

I had also wanted to go directly from ASTs to ASM, say:
   Preproc -> Parser/AST -> ASM -> OBJ -> Binary
Vs:
   Preproc -> Parser/AST -> RIL -> 3AC -> Machine Code -> Binary


But, likely the RIL and 3AC stages are in-fact useful.
And, it now seems like a stack-based IR (for intermediate storage) has 
more advantages than either an SSA based IR (like in Clang/LLVM) or 
traditional object files (like COFF or ELF). Well, except in terms of 
performance and memory overhead (vs COFF or ELF), where in this case the 
"linker" needs to do most of the heavy lifting (and needs to have enough 
memory to deal with the entire program).

A traditional linker need only deal with compiled machine-code, so is 
more a task of shuffling memory around and doing relocs; with the 
compiler parts only needing to deal with a single translation unit. 
Though, the main "highly memory intensive" part of the process tends to 
be parsing and dealing with ASTs, which is gone by the time one is 
dealing with a stack bytecode; but, there is still the memory cost of 
translating the bytecode into 3AC to actually compile stuff. This 
doesn't ask much by modern PC standards, but is asking a lot when RAM is 
measured in MB and one wants to be able to run stuff without an MMU (it 
is a downside if the compiler tends to use enough RAM as to make virtual 
memory essentially mandatory to be able to run the compiler).


But, RIL's design still leaves some things to be desired. As-is, it 
mostly exists as big linear blobs of bytecode, and the compiler needs to 
deal with the whole thing at once. This mostly works for a compiler, but 
would be undesirable for use by a VM (or for a more resource-constrained 
compiler, which can't just load everything all at once).

But, efforts to change this have tended to fizzle out.


> I can only guarantee that I will recognize your work if you do
> this, but that's potentially better than no-one at all. Also, there
> is likely to be more than just me who appreciate having a C90
> compiler in the public domain.
> 
> We currently use the copyrighted GCC 3.2.3 (my modification
> of it) in order to get full C90.
> 
> There are some other targets of interest besides 386, namely
> 370, ARM32, x64, 68000. ARM64 would be good too, but
> we don't have that at all.
> 
> 8086 is another target of interest. SubC is already being used
> to produce a bootloader for PDOS/386, but Watcom is better
> because of SubC's primitive nature.
> 

BGBCC doesn't currently support any 16-bit targets, mostly only 32 and 
64 (well, and an experimental mode that used 128-bit pointers, but this 
was shelved due to "at best, it was gonna suck").


> Thanks. Paul.
> 
> 

[toc] | [prev] | [next] | [standalone]

#18715

"BGB" <cr88192@gmail.com> wrote in message
news:vaoach$3l2k0$1@dont-email.me...

> >> Where, for my own ISA, I am using BGBCC.
> >>     BGBCC is ~ 250 kLOC, and mostly compiles C;
> >
> > We have struggled and struggled and struggled to try to get
> > a public domain C90 compiler written in C90 to produce 386
> > assembler.
> >
> > There have been a large number of talented people who tried
> > to do this and fell flat on their face. I never even tried.
> >
> > The closest we have is SubC.
> >
> > Is this a market gap you are able and interested in filling?
> >
> > By either modifying BGBCC (and making public domain if
> > it isn't already), or using your skills to put SubC over the line?
> >
>
> It is MIT licensed, but doesn't currently produce x86 or x86-64 (as I
> mostly just used MSVC and GCC for PC based development).
>
> Rather, backends it currently has are:
>    BJX2
>    BJX1 and SH-4 (old)
>    BSR1 (short lived)
>      Another custom ISA, inspired by SuperH and MSP430.
> Very early versions targeted x86 and x86-64.
>    But, this backend was dropped long ago.
>    Did briefly attempt a backend for 32-bit ARM, but this was not kept.
>      This was in a different fork.
>      Performance of the generated code was quite terrible.
>      Didn't really seem worth the bother at the time.
>
> Much of the current backend was initially derived from an 'FRBC'
> backend, which was an attempt to do a Dalvik style register IR.
> The FRBC VM was dropped, as while fast, the VM was very bulky in terms
> of code footprint (combinatorial mess). But, at the time, wasn't a big
> step to go from a register IR to an actual CPU ISA, and (for a sensibly
> designed ISA), it is possible to emulate things at similar speeds to
> what one could get with a similar VM.
>
> My current emulator (for BJX2) is kinda slow, but this is more because
> it is usually trying to be cycle-accurate, and as long as it is possible
> for it to be (on the PC side of things) faster than the CPU core on the
> target FPGA, this is good enough...
>
>
>
> AFAIK, whether declaring something as public domain is legally
> recognized depends on jurisdiction. I think this is why CC0 exists.

And if you believe that, then you're welcome to say that this
is public domain, but you may follow the CC0 license instead
if you wish.

> Personally, I am not all that likely to bother with going after anyone
> who breaks the terms of the MIT license, as it is pretty close to "do
> whatever", similar for 3 clause BSD.

We're not after someone who is allegedly "not going to go
after anyone", we're after some code that is NOT OWNED
by the original author because he/she has RELEASED IT
TO THE PUBLIC DOMAIN.

If the answer is "no", then please say "no".

> It is also more C95 style, making significant use of // comments and
> "long long" and similar, more or less the C dialect that MSVC supported
> until around 2015 or so (when they started adding C99 stuff).

Actually, so long as it handles C90 syntax, this would be
a step up from what we currently have.

> I had at one point wanted to try to make a smaller / lighter weight C
> compiler, but this effort mostly fizzled out (when it started to become
> obvious that I wasn't going to be able to pull off a usable C compiler
> in less LOC than the Doom engine, which was part of the original design
> goal).

We don't necessarily need a lighter weight compiler. That
could be done at a later date. The first thing we need is
something that will take C90 syntax.

> I had also wanted to go directly from ASTs to ASM, say:
>    Preproc -> Parser/AST -> ASM -> OBJ -> Binary
> Vs:
>    Preproc -> Parser/AST -> RIL -> 3AC -> Machine Code -> Binary
>
>
> But, likely the RIL and 3AC stages are in-fact useful.
> And, it now seems like a stack-based IR (for intermediate storage) has
> more advantages than either an SSA based IR (like in Clang/LLVM) or
> traditional object files (like COFF or ELF). Well, except in terms of
> performance and memory overhead (vs COFF or ELF), where in this case the
> "linker" needs to do most of the heavy lifting (and needs to have enough
> memory to deal with the entire program).
>
> A traditional linker need only deal with compiled machine-code, so is
> more a task of shuffling memory around and doing relocs; with the
> compiler parts only needing to deal with a single translation unit.
> Though, the main "highly memory intensive" part of the process tends to
> be parsing and dealing with ASTs, which is gone by the time one is
> dealing with a stack bytecode; but, there is still the memory cost of
> translating the bytecode into 3AC to actually compile stuff. This
> doesn't ask much by modern PC standards, but is asking a lot when RAM is
> measured in MB and one wants to be able to run stuff without an MMU (it
> is a downside if the compiler tends to use enough RAM as to make virtual
> memory essentially mandatory to be able to run the compiler).
>
>
> But, RIL's design still leaves some things to be desired. As-is, it
> mostly exists as big linear blobs of bytecode, and the compiler needs to
> deal with the whole thing at once. This mostly works for a compiler, but
> would be undesirable for use by a VM (or for a more resource-constrained
> compiler, which can't just load everything all at once).
>
> But, efforts to change this have tended to fizzle out.

We don't need the world's best C compiler. At least not
as a first step.

> > I can only guarantee that I will recognize your work if you do
> > this, but that's potentially better than no-one at all. Also, there
> > is likely to be more than just me who appreciate having a C90
> > compiler in the public domain.
> >
> > We currently use the copyrighted GCC 3.2.3 (my modification
> > of it) in order to get full C90.
> >
> > There are some other targets of interest besides 386, namely
> > 370, ARM32, x64, 68000. ARM64 would be good too, but
> > we don't have that at all.
> >
> > 8086 is another target of interest. SubC is already being used
> > to produce a bootloader for PDOS/386, but Watcom is better
> > because of SubC's primitive nature.
> >
>
> BGBCC doesn't currently support any 16-bit targets, mostly only 32 and
> 64 (well, and an experimental mode that used 128-bit pointers, but this
> was shelved due to "at best, it was gonna suck").

32 and 64 would be a fantastic start and 99% of the problem..

But if the answer is "no", the answer is "no".

So far the answer is an implied "no".

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18716

On Thu, 29 Aug 2024 11:14:13 +0800, "Paul Edwards"
<mutazilah@gmail.com> wrote:

>"BGB" <cr88192@gmail.com> wrote in message
>news:vaoach$3l2k0$1@dont-email.me...
>
>> AFAIK, whether declaring something as public domain is legally
>> recognized depends on jurisdiction. I think this is why CC0 exists.
>
>And if you believe that, then you're welcome to say that this
>is public domain, but you may follow the CC0 license instead
>if you wish.

BGB is correct: not all countries recognize the notion of "public
domain".

In WIPO convention countries it generally is possible to release a
work under a license that explicitly grants all rights, but the result
is not quite the same as placing the work in public domain.  Without a
legal notion of "public domain" it is not possible for an author to
give up the rights afforded by the (automatic) Berne convention
copyright.

[Of course every country is a WIPO or Berne signatory ... but most
recognize one or both conventions.]

So if you really want a work to be freely usable anywhere in the
world, you can declare it as "public domain" for those countries that
recognize that notion ... but for everywhere else you have to provide
an alternative license that explicitly grants all rights.

[toc] | [prev] | [next] | [standalone]

#18718

On Fri, 30 Aug 2024 06:49:49 -0400, George Neuner
<gneuner2@comcast.net> wrote:

>On Thu, 29 Aug 2024 11:14:13 +0800, "Paul Edwards"
><mutazilah@gmail.com> wrote:
>
>>"BGB" <cr88192@gmail.com> wrote in message
>>news:vaoach$3l2k0$1@dont-email.me...
>>
>>> AFAIK, whether declaring something as public domain is legally
>>> recognized depends on jurisdiction. I think this is why CC0 exists.
>>
>>And if you believe that, then you're welcome to say that this
>>is public domain, but you may follow the CC0 license instead
>>if you wish.
>
>BGB is correct: not all countries recognize the notion of "public
>domain".
>
>In WIPO convention countries it generally is possible to release a
>work under a license that explicitly grants all rights, but the result
>is not quite the same as placing the work in public domain.  Without a
>legal notion of "public domain" it is not possible for an author to
>give up the rights afforded by the (automatic) Berne convention
>copyright.
>
>[Of course every country is a WIPO or Berne signatory ... but most
            ^ not 

>recognize one or both conventions.]
>
>So if you really want a work to be freely usable anywhere in the
>world, you can declare it as "public domain" for those countries that
>recognize that notion ... but for everywhere else you have to provide
>an alternative license that explicitly grants all rights.


Sorry, should have been "... not every country ..."

[toc] | [prev] | [next] | [standalone]

#18719

"George Neuner" <gneuner2@comcast.net> wrote in message
news:t273dj5rpijtmcier4q7bomtgqa3t8rb2t@4ax.com...
> On Thu, 29 Aug 2024 11:14:13 +0800, "Paul Edwards"
> <mutazilah@gmail.com> wrote:
>
> >"BGB" <cr88192@gmail.com> wrote in message
> >news:vaoach$3l2k0$1@dont-email.me...
> >
> >> AFAIK, whether declaring something as public domain is legally
> >> recognized depends on jurisdiction. I think this is why CC0 exists.
> >
> >And if you believe that, then you're welcome to say that this
> >is public domain, but you may follow the CC0 license instead
> >if you wish.
>
> BGB is correct: not all countries recognize the notion of "public
> domain".
>
> In WIPO convention countries it generally is possible to release a
> work under a license that explicitly grants all rights, but the result
> is not quite the same as placing the work in public domain.  Without a
> legal notion of "public domain" it is not possible for an author to
> give up the rights afforded by the (automatic) Berne convention
> copyright.
>
> [Of course [not] every country is a WIPO or Berne signatory ... but most
> recognize one or both conventions.]
>
> So if you really want a work to be freely usable anywhere in the
> world, you can declare it as "public domain" for those countries that
> recognize that notion ... but for everywhere else you have to provide
> an alternative license that explicitly grants all rights.


Isn't that what I just said?

Release it as public domain but say you can use CC0 if you prefer.


BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18720

On Sat, 31 Aug 2024 10:21:53 +0800, "Paul Edwards"
<mutazilah@gmail.com> wrote:

>"George Neuner" <gneuner2@comcast.net> wrote in message
>news:t273dj5rpijtmcier4q7bomtgqa3t8rb2t@4ax.com...
>> On Thu, 29 Aug 2024 11:14:13 +0800, "Paul Edwards"
>> <mutazilah@gmail.com> wrote:
>>
>> >"BGB" <cr88192@gmail.com> wrote in message
>> >news:vaoach$3l2k0$1@dont-email.me...
>> >
>> >> AFAIK, whether declaring something as public domain is legally
>> >> recognized depends on jurisdiction. I think this is why CC0 exists.
>> >
>> >And if you believe that, then you're welcome to say that this
>> >is public domain, but you may follow the CC0 license instead
>> >if you wish.
>>
>> BGB is correct: not all countries recognize the notion of "public
>> domain".
>>
>> In WIPO convention countries it generally is possible to release a
>> work under a license that explicitly grants all rights, but the result
>> is not quite the same as placing the work in public domain.  Without a
>> legal notion of "public domain" it is not possible for an author to
>> give up the rights afforded by the (automatic) Berne convention
>> copyright.
>>
>> [Of course [not] every country is a WIPO or Berne signatory ... but most
>> recognize one or both conventions.]
>>
>> So if you really want a work to be freely usable anywhere in the
>> world, you can declare it as "public domain" for those countries that
>> recognize that notion ... but for everywhere else you have to provide
>> an alternative license that explicitly grants all rights.
>
>
>Isn't that what I just said?
>
>Release it as public domain but say you can use CC0 if you prefer.
>
>
>BFN. Paul.
>

I apologize for any offense.  I only meant to add information for
those who don't know the reason for the discussion.

[toc] | [prev] | [next] | [standalone]

#18721

In article <t273dj5rpijtmcier4q7bomtgqa3t8rb2t@4ax.com>,
George Neuner  <gneuner2@comcast.net> wrote:
>On Thu, 29 Aug 2024 11:14:13 +0800, "Paul Edwards"
><mutazilah@gmail.com> wrote:
>
>>"BGB" <cr88192@gmail.com> wrote in message
>>news:vaoach$3l2k0$1@dont-email.me...
>>
>>> AFAIK, whether declaring something as public domain is legally
>>> recognized depends on jurisdiction. I think this is why CC0 exists.
>>
>>And if you believe that, then you're welcome to say that this
>>is public domain, but you may follow the CC0 license instead
>>if you wish.
>
>BGB is correct: not all countries recognize the notion of "public
>domain".
>
>In WIPO convention countries it generally is possible to release a
>work under a license that explicitly grants all rights, but the result
>is not quite the same as placing the work in public domain.  Without a
>legal notion of "public domain" it is not possible for an author to
>give up the rights afforded by the (automatic) Berne convention
>copyright.
>
>[Of course every country is a WIPO or Berne signatory ... but most
>recognize one or both conventions.]
>
>So if you really want a work to be freely usable anywhere in the
>world, you can declare it as "public domain" for those countries that
>recognize that notion ... but for everywhere else you have to provide
>an alternative license that explicitly grants all rights.

Please don't feed the troll.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#18717

On 29/08/2024 01:03, BGB wrote:
...
>>> Just is seems like a lot of other people are getting lots of
>>> recognition, seem to be doing well off financially, etc.

>>> Meanwhile, I just sort of end up poking at stuff, and implementing
>>> stuff, and it seems like regardless of what I do, no one gives a crap,
>>> or like I am little better off than had I done nothing at all...

seems we two entered the OS-arena from opposite entries,
I started to write my OS on a paying clients demand ... :)

it never was a general purpose system, but successful solutions sold my 
OS w/o any advertising. so I could deliver >200 individual tailored PCs.
Most earned money came from user desired applications rather than from 
OS and hardware [I stopped all hardware production 1997].

all my guaranty and maintenance contracts end this year.
and because I couldn't buy main-boards w/o UEFI&GPT  I stopped working 
on the OS as well.

just recently I was asked by long time clients to give it a try again,
I'm old, tired and I hate all bloatware BS, I started reading UEFI docs.
and I had to learn [hate that like pest] a bit C to convert this huge 
document into technical readable RBIL styled short pages [in progress].
__
wolfgang

[toc] | [prev] | [next] | [standalone]

#18722

BGB-Alt <bohannonindustriesllc@gmail.com> wrote:
> On 7/19/2024 11:18 AM, Scott Lurndal wrote:
>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>> Sure - but why not make it available anyway?
>> 
>> MS-DOS is, was, and always will be a toy.  It's not even
>> a real operating system.
>> 
>> No mainframe user would ever be interested in something
>> so simplisticly useless.
>> 
> 
> It has a FAT filesystem, MZ loader, and basic console printing and 
> memory allocation... These cover the main bases for what one needs for 
> an operating system.

FAT filesytem and MZ executable format means that adding features
would require complete rework.

> Granted, if one wants memory protection and multiple processes/threads, 
> this is no longer sufficient as now the OS needs to be able to do all 
> the other stuff programs might want to be able to do.

Mainframes are too expensive to use them as simple PC from 30 years
ago.  And unlike old PC there is almost no programs ready to
run on Paul's system.

Times have changed and users now want more from their machines.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#18723

"Waldek Hebisch" <antispam@fricas.org> wrote in message
news:vb86lo$rkts$1@paganini.bofh.team...

> Mainframes are too expensive to use them as simple PC from 30 years
> ago.  And unlike old PC there is almost no programs ready to
> run on Paul's system.

When I've "finished", there should be a complete toolchain
and microemacs editor, so any C90 source code should work
(including with embedded ANSI for text fullscreen).

> Times have changed and users now want more from their machines.

Times are changing again, and I want more from my users.

I'm looking forward to the day when everyone switches on their
machines and they're all bricked because Intel and AMD had a
drop dead date in their CPUs.

I'll be last man standing in the Philippines with my Zhaoxin CPU,
and of course the mainframes will still be working.

Or something like that. There was a recent bricking of machines
worldwide due to an ACCIDENT at Crowdstrike.

Now what happens when there is a DELIBERATE attack from
someone in (or who has hacked) Microsoft?

I do my development on Windows 2000 - the last version that
didn't need authentication - and I can run it under Linux on a
Zhaoxin CPU. The Zhaoxin comes with a BIOS (in Chinese -
good grief) - that allows me to run PDOS/386 too.

Last. Man. Standing.

I have my backup plan. Good luck to everyone else.

I charge $1000/minute for programming services, and $1000/minute
for time on my Zhaoxin.

You got PDOS for free though.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18724

On Fri, 6 Sep 2024 07:46:38 +0800, Paul Edwards wrote:

> I'll be last man standing in the Philippines with my Zhaoxin CPU,
> and of course the mainframes will still be working.

Not without power. Without refrigeration city people won't last long.

[toc] | [prev] | [next] | [standalone]

#18725

"J. Curtis" <unknown@protocol.invalid> wrote in message
news:3ikmdj5hv39j2utdpmeo8kb1alobvo4oq2@4ax.com...
> On Fri, 6 Sep 2024 07:46:38 +0800, Paul Edwards wrote:
>
> > I'll be last man standing in the Philippines with my Zhaoxin CPU,
> > and of course the mainframes will still be working.
>
> Not without power. Without refrigeration city people won't last long.

The power grid is dependent on computers being operational?

Regardless, while I am currently in Ligao City, Albay Province,
where I have a manually pumped water well available for when
the public water is either non-existent or dirty, I normally live
halfway between Ligao and Pio Duran. The house opposite us
slaughters pigs at 2am or something.

The grid electricity goes up and down like a yoyo in both places.

I finally found the right portable solar which can be found by
searching for "solar" at pdos.org and I lived for a couple of
months purely off solar for my computing needs. I was using
a Pinebook Pro rather than the Zhaoxin though. While both
have USB-C to charge, only the Pinebook Pro can definitely
be charged from a powerbank. The Zhaoxin says it is
charging but reality appears to be different and I'm not sure
what the situation is and regardless I was planning on getting
a different powerbank.

Actually - I'll take any advice on that. The solar I referenced
has a PD (power delivery) outlet that would potentially give
me a lot more power, but I need a matching outdoor powerbank
to accept it, and I don't know of anything suitable (an Amazon
reference would be good and hopefully they ship to the
Philippines).

I already have Fidonet technology software theoretically operational
on PdAndro on my Android phone that will allow me to replace
the internet. Ditto on PDOS/386 - it was actually tested there.

Admittedly there aren't a lot of people to talk to here, but
hopefully there will be some western refugees turning up in
small boats to access the last operational computer network.

Oh yeah - we have a manually operated well on our normal
property too - also protected by dwendes rather than trolls -
that's a potentially valuable concept that may have been lost
in the West, although in both places we're not actually
drinking that water. I asked if we could boil it but didn't get
a good answer and it hasn't been priority to push the issue.

The irony is that I was happy to be a city slicker in Sydney,
but being in this new environment made me take an interest
in how basic needs were able to be satisfied, and especially
whether we were dependent on Saudi Arabia. I'm obviously
not expecting further deliveries of solar panels, but I will be
armed with some computing power for some time even
without ALECO.

Theoretically.

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18733

> For 35+ years I have wondered why there was no MSDOS for
> the mainframe. I now have an EBCDIC FAT32 file system on
> FBA disks on the mainframe and an operating system that can
> do basic manipulation, like typing files.

And now I can compile C programs, and gccmvs (3.2.3) can
reproduce itself, byte-exact.

Which is what I normally use to judge integrity.

zpg.zip and herc32.zip from https://pdos.org

BFN. Paul.

[toc] | [prev] | [next] | [standalone]

#18685

On Fri, 19 Jul 2024 16:18:13 GMT, Scott Lurndal wrote:

> MS-DOS is, was, and always will be a toy

Small toys and big toys, are all toys.

[toc] | [prev] | [next] | [standalone]

#18753

scott@slp53.sl.home (Scott Lurndal) writes:

> "Paul Edwards" <mutazilah@gmail.com> writes:
>>Sure - but why not make it available anyway?
>
> MS-DOS is, was, and always will be a toy.  It's not even
> a real operating system.

And why is that?  Is it mainly because it doesn't time-share the CPU?

[toc] | [prev] | [next] | [standalone]

#18756

In article <87o6ybbeqw.fsf@example.com>,
Salvador Mirzo  <smirzo@example.com> wrote:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>> "Paul Edwards" <mutazilah@gmail.com> writes:
>>>Sure - but why not make it available anyway?
>>
>> MS-DOS is, was, and always will be a toy.  It's not even
>> a real operating system.
>
>And why is that?  Is it mainly because it doesn't time-share the CPU?

It depends on your definition of an operating system, I suppose.
I like the definition Mothy Roscoe (ETH) used in his OSDI'21
keynote:

The operating system is that body of software that:
1. Multiplexes the machine's hardware resources
2. Abstracts the hardware platform
3. Protects software princples from each other
   (using the hardare)

It's hard to see how MS-DOS fits that definition in a meaningful
way.  Does it multiplex the machine's hardware resources?  Well,
no; not really.  While it does provide a primitive filesystem,
and exposes some interface for memory management, it only lets
one program run at a time, and that program doesn't have to use
or honor DOS's filesystem or memory management stuff.  Further,
the system interface is inexorably tied to the hardware; it's
defined in terms of synchronous software traps and specific
register values.  System calls are numbered, not named.
Finally, the last one is really the nail in the coffin: MS-DOS
makes absolutely no effort to protect the software principles
from each other, or even themselves; a user program can take
over and just never cede control back to DOS. 

So it's hard to see how DOS really qualifies as an OS, despite
the OS-like abstractions it provides.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | alt.os.development

csiph-web