OSDev.org

The Place to Start for Operating System Developers
It is currently Tue Mar 19, 2024 4:27 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 118 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8
Author Message
 Post subject: Re: Test Beds
PostPosted: Wed Oct 26, 2016 1:16 pm 
Offline
Member
Member
User avatar

Joined: Sun Feb 09, 2014 7:11 pm
Posts: 89
Location: Within a meter of a computer
NunoLava1998 wrote:
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.

_________________
"If the truth is a cruel mistress, than a lie must be a nice girl"
Working on Cardinal
Find me at #Cardinal-OS on freenode!


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Fri Oct 28, 2016 3:23 pm 
Offline
Member
Member
User avatar

Joined: Mon Dec 28, 2015 11:11 am
Posts: 401
Are you sure that you are going to test somebody else's code on your main PC?


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Sun Dec 11, 2016 7:17 am 
Offline
Member
Member
User avatar

Joined: Fri Apr 08, 2016 5:03 am
Posts: 132
Location: atapio.cpp - why won't you work :(
Quote:
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 :mrgreen:

_________________
My github page: https://github.com/AlexandreRouma
Meme-deving since 420 Bc !
YouTube: https://www.youtube.com/channel/UCyJnOD ... C8Y7pccc6A
Twitter: https://twitter.com/WhatsTheGeekYT


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Wed May 10, 2017 5:10 am 
Offline
Member
Member

Joined: Sun Apr 23, 2017 4:41 am
Posts: 28
Laptop:
i3 3120M
4GB RAM
500GB SATA3 5400 RPM HDD
Virtual Hardware:
QEMU ARM64 virt board


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Thu May 11, 2017 9:21 am 
Offline
Member
Member
User avatar

Joined: Sun Jul 14, 2013 6:01 pm
Posts: 442
-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

_________________
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Fri Sep 01, 2017 5:35 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
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


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Fri Mar 09, 2018 2:17 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
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. :-)


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Sat Sep 18, 2021 3:17 pm 
Offline
Member
Member
User avatar

Joined: Fri Sep 03, 2021 5:20 pm
Posts: 91
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.


Image

Image


Attachments:
WP_20170308_20_08_57_Pro.jpg
WP_20170308_20_08_57_Pro.jpg [ 120.96 KiB | Viewed 15401 times ]
WP_20170308_20_07_25_Pro.jpg
WP_20170308_20_07_25_Pro.jpg [ 100.15 KiB | Viewed 15401 times ]

_________________
Writing a bootloader in under 15 minutes: https://www.youtube.com/watch?v=0E0FKjvTA0M


Last edited by BigBuda on Tue Mar 05, 2024 3:51 pm, edited 1 time in total.
Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Sat Sep 18, 2021 5:55 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5069
BigBuda wrote:
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...

BigBuda wrote:
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...


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Sun Sep 19, 2021 12:47 am 
Offline
Member
Member
User avatar

Joined: Fri Sep 03, 2021 5:20 pm
Posts: 91
Octocontrabass wrote:
BigBuda wrote:
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...

BigBuda wrote:
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.

Octocontrabass wrote:
(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.

_________________
Writing a bootloader in under 15 minutes: https://www.youtube.com/watch?v=0E0FKjvTA0M


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Mon Dec 20, 2021 3:15 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 811
Location: Hyperspace
BigBuda wrote:
Octocontrabass wrote:
BigBuda wrote:
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...

BigBuda wrote:
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. :D 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.)

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Mon Dec 20, 2021 5:35 pm 
Offline
Member
Member
User avatar

Joined: Fri Sep 03, 2021 5:20 pm
Posts: 91
eekee wrote:

All the same, I'd have been scared to do it, too. :D 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.

_________________
Writing a bootloader in under 15 minutes: https://www.youtube.com/watch?v=0E0FKjvTA0M


Top
 Profile  
 
 Post subject: Re: Test Beds
PostPosted: Mon Mar 04, 2024 7:28 pm 
Offline
Member
Member

Joined: Tue Oct 10, 2023 7:40 pm
Posts: 27
Is this thread still valid?
its been over 2 years since last post


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 118 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group