Test Beds

[hgoel]

i know, just comparing to the systems here which aren't very good.

Only, they aren't bad from the point of view of testing for operating systems. For testing an OS the point isn't to necessarily test on fast hardware, but on different hardware. The more variety, the better the testing.

[Ycep]

Are you sure that you are going to test somebody else's code on your main PC?

[DeezRamChips]

Screen: 1680 x 1050 x 32


xXxX_EXTR3M3_R3S0LUT1ONZ_XxXx
nice screen m8

Thnks m9 xDDDDD

I s33 im n0t teh only m3me L0v3r h3re

[gungomanj]

Laptop:
i3 3120M
4GB RAM
500GB SATA3 5400 RPM HDD
Virtual Hardware:
QEMU ARM64 virt board

[Geri]

-i have one working computer from all the 4 most popular x86 cpu manufacturers of todays.
-i have also an old socket7 motherboard with a lot of cpu-s from various cpus from the past.
-i temporally removed the ARM solutions from testing

[BenLunt]

The other day I saw that my UHCI driver was acting up on a certain device so I decided to test it out. I grabbed six (older) computers out of storage and decided to see if it was the UHCI controller or the device that my code didn't like. Come to find out, it was both. After some testing, research, and much trial and error, I got it working much better on all six computers and three emulators (not to mention finding a quirk in Bochs and VirtualBox ).

Anyway, since I still have these machines out, I thought I would offer them for testing if you will repay the favor. (Testing the whole machine, not just USB)

However, I do have a few small requirements.
1a) Must be a 1.44Meg floppy image that I can write to a real floppy and boot from it *or*
1b) Must be an image that I can write to a USB flash drive and boot from it. However, it must be a tested and tried bootable image for USB.
2) Must not try to install or (intentionally) write to any media other than the booted media, though it can read from installed IDEs, ATA, SATA, AHCI's, USB's, etc.

If you wish to, but not a requirement, just a favor for me testing yours, please try mine at:
http://www.fysnet.net/fysos/floppy.img
(http://www.fysnet.net/fysos.htm)
The first link is the (uncompressed) 1.44Meg floppy image ready for testing. I have not tried it with a bootable USB thumb drive (yet).

The booted OS will pretty much only detect all hardware and media, booting to a simple DOS like prompt. If you wish, you can type "gui" at the prompt and the GUI will start, though I currently only have a few items compiled in for testing.

While booting (at the blue screen), you may press F9 to stay in text mode (suggested for testing) or press F8 to choose a video mode. However, you must use a video mode to try the (minimal) GUI. (With this in mind, it will only boot from a Legacy BIOS machine. My UEFI boot is on the second URL above, though not updated to the new/fixed code)

After you have booted (or exited the GUI), please type "write_debug" at the A:\ prompt and the OS will write all my debug stuff to the disk. I would appreciate this DEBUG.TXT file (fys[at sign goes here]fysnet[dot sign goes here]net)

Post here (or message me) a link to your image with a little instruction, and I will try to frequent this thread for the next week or so.

Thank you,
Ben

P.S. I have been working on my USB book and need a few more USB devices for testing. I have tested quite a few but could always use more tests. If you have an old USB device somewhere, collecting dust, wasting space, etc., and wish to send it my way, I would be sure and include your name in the next edition, as I have with the previous contributors. Thank you. (message me or email me for mailing instructions).

EDIT #1: Just for fun, I have uploaded a pic of four of the six machines mentioned. Each has various hardware items, most recent to maybe 2005 or so. Nothing really new. All are 32-bit x86 machines.

EDIT #2: I now have a Thumb Drive ready image for booting on Legacy BIOS USB allowed machines. http://www.fysnet.net/zips/fysos.zip

[BenLunt]

Coming from viewtopic.php?f=1&t=12087&p=282624#p282624, where this subject should not be pursued further, I am just announcing that if you have a bootable USB Thumb Drive image[1] ready for testing, I am willing to test on one or more of my machines.

If it were not for a fellow reader, I would not have found a serious bug in my code, so I wish to repay the favor. On that note, I would ask that if you are so inclined, that you test mine as well as others.

Information for mine is at http://www.fysnet.net/blog/2018/03/. As previously stated, with all the tests I have done, it works just fine, but with a fellow readers proof, that isn't the case. If you get to the end, a simple "wd" and a copy to another machine with email is all that is needed. However, you may not even get a valid boot, and thanks to this fellow reader, he/she sent images taken with his/her phone of the screen, which was very helpful.

If the moderators are okay with it, please post a little information about yours, and maybe a particular subject you are testing for.

Please note that I will not test yours on my flagship, nor a few of my other machines. With that said, I don't expect you to either. If you have an older machine, or a newer one, that you wish to test on, please do. I have four or five older 32-bit Intel/AMD machines that I don't mind testing other's with.

Thank you,
Ben

[1] I also have a few machines that still have floppy drives, so if you must, a 1.44meg image is fine too, though please state that you are specifically testing for floppy use or I will assume an USB Thumb drive boot. On a side note, I still have working 5 1/4" drives, and have a working 8" floppy drive with disks, though I do not have a controller adapter for it. I have been meaning to make one though.

[BigBuda]

Hi all

This is (I think so at least) going to be an interesting story, so read on. I think my testbed will be an example of how a (then) innocent teenager manages to find workarounds. Back in the mid to late 90's, I was building my own OS. I managed to get it to boot to a point, entering protected mode and all and that was almost as good as an o..., well... you know what word I was going to say.

My setup at the moment was a Cyrix 4x86 with split numeric coprocessor (x87) that was the first PC that I built myself. I got the parts from several sources, mostly second hand, some new. I did almost all the development of my OS on DOS, using DJGPP and NASMIDE as IDEs. The machine's specs were as follows:

Cyrix 4x86 + x87
8MB RAM
Philips PCA721AF soundcard
NE2000 ethernet card (later 2xNE2000 when I repurposed it as a router)
3GB Seagate hard drive
20GB Maxtor hard drive (later replaced by a 120GB IBM Deskstar)
Schneider VCM14 monitor
Schneider PC/AT keyboard (top 3 best keyboards I've ever had)
Cirrus Logic GD5422 Video card
Philips 36X CDROM drive

Seems like a pretty standard machine at first, except for the unusually large hard drives for an already obsolete machine. However, there was a catch. As I was developing my OS, I needed a way to test it. Emulators were a no go on that machine and because of the hardware and the way it was installed (emulators on DOS?), boot managers were also not an option.

So, what did I do? Well, with a soldering iron in one hand, a microswitch and a few motherboard jumper cables in the other, I macgyvered a simple yet effective workaround for my problem. Since drives at the time were all IDE with the jumpers to select between master and slave, what I did was use a DPDT microswitch to control which drive was master and which was slave with every reboot. So, I'd develop my OS in my main drive (3GB Seagate), where I had DOS 6.22 and all the tools installed, and I'd install it on the second drive (20GB Maxtor). Then I'd flip the switch, force a triple fault or power cycle and the booting drive would have switched to be the Maxtor instead of the Seagate. I'd test the OS, then flip the switch again and power cycle again to go back to DOS. Those were fun times.

Because a picture is worth more than a thousand words, there's a couple thousand words for you attached to the post, as proof.

[Octocontrabass]

Since drives at the time were all IDE with the jumpers to select between master and slave, what I did was use a DPDT microswitch to control which drive was master and which was slave with every reboot.

Given the way IDE works, this is a rather scary proposal. I'm sure it's fine if you only flip the switch while the computer is off, but...

force a triple fault

Yikes! I'm surprised that was enough to reset the drives correctly.

(And of course you always had the option of installing your OS on a floppy disk instead of a hard disk, or writing your own boot manager and using that to boot your OS from the second disk.)

I've actually been using a couple of 486-based PCs of similar vintage for my most recent bare metal testing, although I spend more time reverse-engineering the undocumented jumpers than testing my OS whenever I pull those out...

[BigBuda]

Since drives at the time were all IDE with the jumpers to select between master and slave, what I did was use a DPDT microswitch to control which drive was master and which was slave with every reboot.

Given the way IDE works, this is a rather scary proposal. I'm sure it's fine if you only flip the switch while the computer is off, but...

force a triple fault

Yikes! I'm surprised that was enough to reset the drives correctly.

For some reason, on triple fault that board would reset all hardware, so... go figure.

(And of course you always had the option of installing your OS on a floppy disk instead of a hard disk, or writing your own boot manager and using that to boot your OS from the second disk.)

I didn't even consider floopies at the time and writing the bootmanager would imply doing all of this anyway. Most of the time spent flipping the switch was to test the booting process, so... But it worked. No drives were harmed while shooting this movie.

[eekee]

Since drives at the time were all IDE with the jumpers to select between master and slave, what I did was use a DPDT microswitch to control which drive was master and which was slave with every reboot.

Given the way IDE works, this is a rather scary proposal. I'm sure it's fine if you only flip the switch while the computer is off, but...

force a triple fault

Yikes! I'm surprised that was enough to reset the drives correctly.

For some reason, on triple fault that board would reset all hardware, so... go figure.

It would do. A triple fault is a fairly normal way to reboot, and hardware was expected to reset on reboot. In the late 90s, Linux kernel documentation warned of one particular CD-ROM drive which was found not to reset on anything other than a cold boot, just like it did of one particular chipset with broken IDE acceleration.

All the same, I'd have been scared to do it, too. I respect BigBuda for having done it and found it works, but my plan was writing or patching a bootloader to read a switch connected to the parallel port. I never implemented it. A simpler idea was a floppy disk with a minimal bootloader which just loads a specific partition regardless of the 'active' flag. Insert disk to boot partition A, remove to boot partition B. This can be achieved with LiLo, but the idea of 'minimal' was to reduce the time taken to load from the slow floppy disk. (I think LiLo actually installs a fairly minimal bootloader, but its config gives me a headache anyway.)

[BigBuda]

All the same, I'd have been scared to do it, too. I respect BigBuda for having done it and found it works, but my plan was writing or patching a bootloader to read a switch connected to the parallel port. I never implemented it. A simpler idea was a floppy disk with a minimal bootloader which just loads a specific partition regardless of the 'active' flag. Insert disk to boot partition A, remove to boot partition B. This can be achieved with LiLo, but the idea of 'minimal' was to reduce the time taken to load from the slow floppy disk. (I think LiLo actually installs a fairly minimal bootloader, but its config gives me a headache anyway.)

Well, thanks, I guess XD those were simpler times, when I was younger and reckless. I'd never use the floppy because it was too slow for me (it was bad enough for little impatient me having to reboot it). It was a good workaround that could have gone bad, but really paid off. Had it booting in no time.

[Xeno]

Is this thread still valid?
its been over 2 years since last post