Re: Re: Computer Broken
By: poindexter FORTRAN to apam on Wed Sep 10 2025 06:38 pm

My local junk shop has an old, serial Logitech mouse - the wedgy one with the 3 buttons. I'll see if it's still there. :)

Hah! Cool. Except I don't have a serial mouse driver either lol

Andrew
--- SBBSecho 3.28-Win32
* Origin: -=[conchaos.synchro.net | ConstructiveChaos BBS]=- (21:4/141)

On 10 Sep 2025 at 06:56p, apam pondered and said...

[snip]
I'm going away for a week tomorrow, going to investigate USB stack and porting to x86_64 - both seem like pretty monumental tasks to me lol, so which ever one looks the easiest I will have a crack at first.

Cool. USB is hard; for x86_64, it depends: to enter 64-bit
long mode, you have to set up virtual memory paging and enable
the MMU; if you're already doing that for 32-bit, it's not so
bad: but if you're using x86-segmentation (which I think you
are?) it's a lot more challenging because a) most of x86
segmentation is ignored in long mode, and b) you have to switch
to paged virtual memory (with at least 4 level paging).

Personally, I'd rather set up a kernel for x86_64 than implement
USB, particularly if I have to do HID devices.

Hey, that's all pretty cool! Dunno about the VirtualBox stuff, but g luck and have fun playing around with it!

Thanks, I'm pretty happy with it.. I discovered some errors in it
earlier this year and it's been running so much better since I fixed
them, and I've been suprised at how well the networking has been going
(I had a webserver on it for weeks, and with all the portscanners and such, it didn't crash at all)

Anyway, I will have fun, oh I used your pointer vectors in it too that
you contributed to magicka bbs - I hope that's ok..

Sure! Have at it.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Re: Re: Computer Broken
By: tenser to apam on Fri Sep 12 2025 11:03 am

Cool. USB is hard; for x86_64, it depends: to enter 64-bit long mode, you have to set up virtual memory paging and enable the MMU; if you're already doing that for 32-bit, it's not so bad: but if you're using x86-segmentation (which I think you are?) it's a lot more challenging because a) most of x86 segmentation is ignored in long mode, and b) you have to switch to paged virtual memory (with at least 4 level paging).

no i do have paging with the mmu. I'll look at it. I did go down another rabbit holr though, adding fat support via grafting the fatfs driver in, its _almost_ working, but having some minor issue that is proving to be difficult :)

my goal for adding fat support was to be able to use usb keys which would be awesome if i had a usb stack, and able to use limine boot loader which i hear is good (and part of a youtube video about porting to x86_64) plus having to have an OS that can write minix v3 filesystems to prepare my disk images is a bit tricky (debian does still, but most linux distros ship kernels with it disabled)

Andrew
--- SBBSecho 3.28-Win32
* Origin: -=[conchaos.synchro.net | ConstructiveChaos BBS]=- (21:4/141)

apam wrote to poindexter FORTRAN <=-

Hah! Cool. Except I don't have a serial mouse driver either lol

I would love to have one of those swoopy Logitech mice, that was sort of
peak Logitech design, around the late '90s. Don't know if I could
tolerate a mechanical mouse again - I spent most of the '90s cleaning
mouse gerb out of the workings...



... Dear Esteemed Colleagues (And Steve);
--- MultiMail/Win v0.52
* Origin: realitycheckBBS.org -- information is power. (21:4/122)

Re: Re: Computer Broken
By: poindexter FORTRAN to apam on Fri Sep 12 2025 07:01:04

Hi, pF.

Don't know if I could
tolerate a mechanical mouse again - I spent most of the '90s cleaning
mouse gerb out of the workings...

I remember when optical mice (without the special 'graph paper' reflective mat) started to become mainstream. "What a pointless change", I thought at the time.

Now in the 2020s I get to use a ball mouse (or "mouse", as they used to be called) again and... Man, are they crap!

I spent an embarrassingly long time thinking my ball mouse was broken - actually it was too begin with, an ex school mouse which has a Phillips screw to stop kids pinching the ball and so some genius had tried to pry it out with a pencil and made the circular hole no longer circular. Anyway, I continued heating and straightening and sanding that long after I probably needed to because I forgot the golden rule: ball mice need a mouse mat!

Well, I don't have any of them but the cardboard back of a writing pad works a lot better than my shiny desktop.

BobW
--- SBBSecho 3.29-Linux
* Origin: >>> Magnum BBS <<< - magnumbbs.net (21:1/205)

On 12 Sep 2025 at 05:51a, apam pondered and said...

Re: Re: Computer Broken
By: tenser to apam on Fri Sep 12 2025 11:03 am

Cool. USB is hard; for x86_64, it depends: to enter 64-bit long mode have to set up virtual memory paging and enable the MMU; if you're al doing that for 32-bit, it's not so bad: but if you're using x86-segmentation (which I think you are?) it's a lot more challenging because a) most of x86 segmentation is ignored in long mode, and b) y have to switch to paged virtual memory (with at least 4 level paging)

no i do have paging with the mmu. I'll look at it.

Ah, cool. I stand corrected!

I did go down another
rabbit holr though, adding fat support via grafting the fatfs driver in, its _almost_ working, but having some minor issue that is proving to be difficult :)

Oh nice. What's the problem that you hit? Possibly you've already
fixed it by now, but I'm curious.

my goal for adding fat support was to be able to use usb keys which
would be awesome if i had a usb stack, and able to use limine boot
loader which i hear is good (and part of a youtube video about porting
to x86_64) plus having to have an OS that can write minix v3 filesystems to prepare my disk images is a bit tricky (debian does still, but most linux distros ship kernels with it disabled)

It strikes me that you could probably still use limine regardless
of whether the OS used a different file system format: you'd just
prepare an image with a copy of the kernel in a small FAT
partition, but the system would mostly ignore it once running.

I presume to prepare an image, you attach a file to a pseudo disk
device via a loopback driver and initialize and mount a Minix FS
on it, then just copy files to that. You could, however, create
a filesystem directly in a disk file and copy files into that; it
would be a fair bit of work, as you'd have to write code to write
the minix3 file structures into that file, versus letting the kernel
do that for you, but it would be very portable. Of course, using
FAT would be much simpler.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Oh nice. What's the problem that you hit? Possibly you've already
fixed it by now, but I'm curious.

It was actually an issue with my memcmp function, i was comparing an
extra byte.. no idea how that one snuck by for so long!

It's all working now :D

It strikes me that you could probably still use limine regardless
of whether the OS used a different file system format: you'd just
prepare an image with a copy of the kernel in a small FAT
partition, but the system would mostly ignore it once running.

Yes, I did try that first, but it didn't work - I assumed I had an error loading from the second partition, but I didn't dig in and went the fat
route instead, I should try again! Part of the reason was Limine passes
the frame buffer info a bit differently to grub (not incorrectly, just a
way I hadn't realized could be done, so thats fixed now too)

I presume to prepare an image, you attach a file to a pseudo disk
device via a loopback driver and initialize and mount a Minix FS
on it, then just copy files to that. You could, however, create

Yep! that's exactly what I am doing

a filesystem directly in a disk file and copy files into that; it
would be a fair bit of work, as you'd have to write code to write
the minix3 file structures into that file, versus letting the kernel
do that for you, but it would be very portable. Of course, using
FAT would be much simpler.

Yeah, it's possible, but yeah, a lot of work, and filesystems are
something I struggle with a bit. I did think instead I could write a
minix3 FUSE driver, then it might port to use with FUSE on other systems.

Fat is also much better, my minix 3 driver only supports 1024 block size,
which appears to make filesystems restricted to small sizes. I'm not sure
if thats an error on my part, as when I was writing it I understood that
they could only be 1024 block size, but I think that was incorrect.

Now that the FAT driver is working, I've been able to port all my scripts
to use FreeBSD, which is great, means I'm not stuck on Linux if I don't
want to be :)

Andrew


--- envy/0.1-6dee535
* Origin: Quinn - Random Things - bbs.quinnos.com:2323 (21:3/197)

On 14 Sep 2025 at 08:58p, apam pondered and said...

Oh nice. What's the problem that you hit? Possibly you've already fixed it by now, but I'm curious.

It was actually an issue with my memcmp function, i was comparing an
extra byte.. no idea how that one snuck by for so long!

Oh great! It's surprising how long a small bug like that can
last, and how far you can still get while it does.

[snip]

a filesystem directly in a disk file and copy files into that; it
would be a fair bit of work, as you'd have to write code to write
the minix3 file structures into that file, versus letting the kernel
do that for you, but it would be very portable. Of course, using
FAT would be much simpler.

Yeah, it's possible, but yeah, a lot of work, and filesystems are something I struggle with a bit. I did think instead I could write a minix3 FUSE driver, then it might port to use with FUSE on other systems.

Honestly, it's probably not worth it, and if you've got a working
fat implementation, then no need to bother. It may be interesting,
though!

Fat is also much better, my minix 3 driver only supports 1024 block size, which appears to make filesystems restricted to small sizes. I'm not sure if thats an error on my part, as when I was writing it I understood that they could only be 1024 block size, but I think that was incorrect.

The Minix filesystem is pretty, well, minimal, even for v3. It looks
an awful lot like the 7th Edition Unix filesystem, or perhaps that FS's incarnation as "S5" in System V. Anyway, yeah, it allocates space in
chunks of "zones" (which are 1024-byte blocks), but it supports up to
a triply-indrect block, so you can allocate a pretty big number of
zones to a file; theoretically, maximum file sizes would be in the gigs. However, the size field in the inode is a signed 32-bit integer, so in
practice any given file is limited to 2GiB or so. You could stretch
the size out to 64 bits and bump the zone size up to 4KiB or so and
that would make more or less let you address TiB of space, but you
wouldn't be able to use any of the existing tools to manipulate the
filesystem externally.

Now that the FAT driver is working, I've been able to port all my scripts to use FreeBSD, which is great, means I'm not stuck on Linux if I don't want to be :)

Hey, that's great! No need to futz around with the Minix3 FS, then.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Oh great! It's surprising how long a small bug like that can
last, and how far you can still get while it does.

Oh I know!

Honestly, it's probably not worth it, and if you've got a working
fat implementation, then no need to bother. It may be interesting,
though!

Yeah, I'm not sure it'w worth it either - unless I'm wanting to learn how
FUSE works (which may be a good way to port file system drivers in the
future? hmm)

Hey, that's great! No need to futz around with the Minix3 FS, then.

Yup, when I first started writing this OS, I had used FAT, but my implementation was very buggy and I ended up getting minix filesystem
working as a second filesystem, and it worked better so I just removed my
fat code.

Finding the FatFS driver was great though, because it's already well
tested - having a filesystem that I can rely on means easier to find
other bugs.. it's hard to debug your programs when they don't even load
off the disk correctly!

Are you still working on that Rust port of .... I can't remember the name
of that OS - was a unix os that got ported to RISCV i think...

Andrew


--- envy/0.1-6dee535
* Origin: Quinn - Random Things - bbs.quinnos.com:2323 (21:3/197)

On 15 Sep 2025 at 11:02p, apam pondered and said...

Honestly, it's probably not worth it, and if you've got a working
fat implementation, then no need to bother. It may be interesting, though!

Yeah, I'm not sure it'w worth it either - unless I'm wanting to learn how FUSE works (which may be a good way to port file system drivers in the future? hmm)

If you want to be able to work with the filesystem using the
host's complement of standard tools (text editors, grep, awk,
sed, all that good stuff) then yeah, I think that's a decent
want to go. I'm not a _huge_ fan of FUSE myself (the Plan 9
way of using 9P for everything was conceptually a lot more
elegant) but hey, that's just me.

Finding the FatFS driver was great though, because it's already well tested - having a filesystem that I can rely on means easier to find
other bugs.. it's hard to debug your programs when they don't even load off the disk correctly!

Yup. A stable place to stand is essential in order to use your
lever to move the world.

Are you still working on that Rust port of .... I can't remember the name of that OS - was a unix os that got ported to RISCV i think...

I believe you mean rxv64, which was a Rust rewrite of xv6, but
retargeted to x86_64, instead of 32-bit x86. I keep it working,
but that project is basically done.

I did that for a very specific purpose: we had a project where
we were working on a new hypervisor that ran directly on the
bare metal, and doing so in Rust. The issue was that we had a
lot of people from Google cloud working on the project; all of
them were excellent software engineers, but mainly had experience
working in C and C++ at the application level on Linux, not at
the kernel level and not in Rust. In order to ramp them up on
kernel development, we were pointing them at MIT's course
materials that used xv6; the feedback from that was "this is great,
but it's 32-bit specific and it's in C." So I did rxv64 as an
additional resource; that was helpful, but it was always meant as
a pedagogical aid (and one for working engineers), not a production
system.

Still, elements of it have shown up in various places. For instance,
the exception handling code for the production bootloader on the
Oxide machine is derived from rxv64: https://github.com/oxidecomputer/phbl/blob/main/src/idt.rs

(We use it on the development bootloader/debugger, as well: https://github.com/oxidecomputer/bldb/)

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

I believe you mean rxv64, which was a Rust rewrite of xv6, but
retargeted to x86_64, instead of 32-bit x86. I keep it working,
but that project is basically done.

Yes, that's what I was thinking of.

but it's 32-bit specific and it's in C." So I did rxv64 as an
additional resource; that was helpful, but it was always meant as
a pedagogical aid (and one for working engineers), not a production
system.

Heh, that's cool - I didn't realize it was done for a particular reason.

Still, elements of it have shown up in various places. For instance,
the exception handling code for the production bootloader on the
Oxide machine is derived from rxv64:

That's cool, I'll have to have a look. I see a lot of posts from people associated with and about Oxide on mastodon. Sounds like an interesting
place to work at.

Andrew



--- envy/0.1-6dee535
* Origin: Quinn - Random Things - bbs.quinnos.com:2323 (21:3/197)

On 17 Sep 2025 at 07:53a, apam pondered and said...

I believe you mean rxv64, which was a Rust rewrite of xv6, but retargeted to x86_64, instead of 32-bit x86. I keep it working,
but that project is basically done.

Yes, that's what I was thinking of.

but it's 32-bit specific and it's in C." So I did rxv64 as an additional resource; that was helpful, but it was always meant as
a pedagogical aid (and one for working engineers), not a production system.

Heh, that's cool - I didn't realize it was done for a particular reason.

Yeah. Some other bits came out of it; the process of doing
the port revealed a few bugs in xv6 itself, which I fixed and
contributed back to MIT.

At one point, I talked briefly to both them and Phil Levis at
Stanford about adopting rxv64 for their OS classes, but the
consensus was that teaching Rust _in addition_ to the OS side
would likely be too high of a mountain to climb for most
students. For all its warts and failures, C is just easier to
teach in the first week or so of a course, so that students
can get to the good stuff. And for the higher-level stuff, the
MIT folks prefer Go to Rust (not surprising since Go is basically
run by their former students!).

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

On 17 Sep 2025 at 07:53a, apam pondered and said...

That's cool, I'll have to have a look. I see a lot of posts from people associated with and about Oxide on mastodon. Sounds like an interesting place to work at.

It is. No one else is really doing the sort of thing we're trying
to do (at least, not that I'm aware of). There's a lot more I wish
we could do on the software side, but hopefully that'll come as the
business matures.

--- Mystic BBS v1.12 A48 (Linux/64)
* Origin: Agency BBS | Dunedin, New Zealand | agency.bbs.nz (21:1/101)

Yes, that's what I was thinking of.

Heh, that's cool - I didn't realize it was done for a particular reason.

That's cool, I'll have to have a look. I see a lot of posts from people associated with and about Oxide on mastodon. Sounds like an interesting
place to work at.

Andrew

--- envy/0.1-6dee535
* Origin: Quinn - Random Things - bbs.quinnos.com:2323 (21:3/197)

While reading your posts I see the word "Quinn" in the Origin line .
Makes me think of Paul Quinn who I wrote to in the FIDO Windows 95 echo .
Ed
--- SBBSecho 3.28-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (21:1/175)