wierd_w

Hard wired logic, instead of microcode. This allows some operations to be completed in a single execution cycle instead of several.

Back when, I had an actual scholastic need for a functional mac emulator / runtime environment. This was because my teachers insisted that all computer-typed homework must be in claris works format, because that is what was on all the school's macs. The trouble, was that I was a PC kid. (and no, the PC version of claris works did not interoperate well with the mac version at all.) There was a bit of software called ARDI Executor, which was basically a mac runtime environment coupled with a 68k jit emulator. It wasn't the prettiest thing, but it could run older claris works meant for system 6 and 7, and could work with mac formatted diskettes. There was a demo, but it had... restrictions... that made it unsuitable for my needs, but hinted that the full version would do what I needed. I remember begging for a copy from my folks, and being met with dumbfounded expressions of why I would want or need such a thing. I made due without it-- hunting for copies of Fusion instead. I ultimately got some shoestring and bailing wire together with Fusion and pirate mac roms, but I still wanted that copy of ARDI executor. Never did get it. The company folded long before I became employed, and thus able to make the purchase myself. Its available as an open sourced project now, I understand, but my need for it has long elapsed, and I am better served with SheepShaver or Basilisk II these days. https://www.macintoshrepository.org/25615-ardi-executor (thats one for windows, apparently-- but my system was a 486sx, and having windows running was a show stopper on performance. I needed/wanted the dos version.) just for completeness, along with https://www.emaculation.com/doku.php/fusion (which runs on DOS, and can reasonably run 68k mac OS 7 on such a vintage rig. It's what I ultimately ended up using instead to get around the format wars BS my teachers were pushing.)

Success! I successfully installed win7 on it. (Win7 is not able to be installed on an EFI only system. This meant that previously, the oldest I could run on this thing was win8, and that is... Yeah.) I should be able to boot DOS, and any number of other legacy OSes on this thing now. Sadly, it has an HD Audio bus device, and HDMI only intel video, but it does have a real SATA port. One thing I might try, is loading an old Novel Netware 5.1 install on it, just because. LOL

Coreboot + seabios appears to be successfully flashed. This makes the minnowboard better suited for some older OSes, like win7 and older. I can turn this thing into a fun little project now that it can boot older OSes. (It's too weak kneed to be a proper desktop with a more modern OS, but its ~2ghz clockspeed and 2gb of RAM is just right for an older OS.) I am currently cooking a win7 install media USB stick. I will see how well this thing works with seabios.

I dug harder. Found instructions for building coreboot+seabios for that platform. Built a rom image. Will try to flash.

Actually, i kinda lied. There WAS a foss uefi bios based on coreboot with seabios, called sagebios, for this platform, but I cannot find a working download. If someone can find it, i would be thankful.

So, i have a bit of oddware. It's an old Atom based SBC, called a minnowboard max. https://elinux.org/Minnowboard:MinnowMax Sadly it is EFI only, with no CSM, so no native DOS. However, I am looking for project ideas for it. It's just sitting around, when it could be fun.

The fan 'might' be resurrectable... remove it from the system, note its power needs and polarity, then submerge it in a plastic basin full of isopropyl. Connect the power, and give it a manual push to start it turning, and let it push the liquid around a few minutes. It will dislodge a good deal of the filth that has been sucked into the fan. It wont fully recover an old fan though. Best to just replace it, but as a temp fix while awaiting that replacement in the mail, it works, usually.

It's a 6-ish pin IDC connector on the SB-LIVE! (and other PCI cards that supported it), and on the motherboard. A pigtail connects them. I have never used it. Not all motherboards from the era even supported it. It was for getting around the differences between ISA DMA and PCI DMA, as well as ISA IRQ and PCI IRQ, so that PCI cards could more effectively emulate ISA ones. From here:

Theoretically, you could manage the SAMS manually from normal extended basic, it would just be.. Annoying. (Making sure that your segment is proper for your variable arrays, etc... so that they properly "move" on page, with manual paging by jiggling the CRU the hard way with CALLs) Having the interpreter be aware of it makes things much easier. Admittedly though, having to do it the hard way WOULD get you very intimate with the workings of the SAMS card.

I would suggest a 32mb one. This could be an issue with trying to parse a very large fat, in a timing sensitive operation. A very small fat may resolve the issue. (Either alter the partition to make it real small on a larger card, or use the smaller card) Other considerations: What does the partition table of the sdcard look like on the troubled units? Perhaps there is an issue with tables made with certain tools or OSes.

I would suggest finding a functional basic interpreter, then porting some games. Looks like you can get disk images of the system software an the msbasic disk here. http://www.retroarchive.org/maslin/disks/osborne/index.html That should greatly increase your (potential) game library. In addition to the msbasic interpreter, there was also a compiler. I've read it took msbasic files without modification and spat out machine code that runs ~300% faster. Good luck finding it though.

You should comment on that desire in the actual development thread. The current design does not have such a wait function. Adding one should be reasonably trivial though. (A capacitor, a single bit latch, and some resistors would be cheapest I think?)

He is apparently designing a small circuit to handle power on/off using the momentary button. With a modification, a few seconds delay could be induced. that would make it a non-issue.

Boring technical prattle about sdcards These sata->ide bridges still provide 512 byte or 4096 byte hardware sectors, and the transport is already pretty fast. A modern sata drive will be waiting on the ide drive to do stuff,

Properly used with a filesystem that can make effective use of it (ExFAT being the industry go-to, but EXT4 and BTRFS can both use it effectively when set up right), SDCard is both cheap, and reasonably performant. You just have to keep its limited write life in mind. Your SATA->IDE bridge is by far a better solution though.

SD card is not intended for 512 byte sectors, is the deal. Its meant for closer to 4mb sectors.

How about a 10$ interposer to go with your cheap slotket? https://www.ebay.com/itm/283583586110?hash=item4206e61f3e:g:8vMAAOSw88NdWCZ~

Modern multi-core processors are a combination of SMT (Multi-threading, usually with 2 hardware threads), and on-chip SMP. That is probably why there is confusion. (and why a quad core chip shows up with 8 threads in task manager) HyperThreading was... Not true multithreading. A multithreading capable CPU has sufficient APUs inside to handle 2 genuine hardware threads at once. HT on the other hand, can handle 1 hardware thread and sometimes, another thread-- depending on what parts of the CPU were not being used by the first thread. EG, logic operations in one thread, and floating point in the other, is perfectly peachy. However, when you have a video driver going "Oh, the system load on 'core 0' (because the OS did not have a way to tell software "no, this is really hardware thread 0!") is really high, I will use 'Core 1' for this math intensive task! (or maybe storage driver, say-- disk compression needing math functions?), when the main thread is already using those processor functions--- you get processes that get desyncronized, processes forced into waitstates, or into spinlock hell, which, for time-sensitive IO operations, can lead to bluescreens and crashes. HT was an interesting idea. Just, SMP, with multiple actual CPUs on the board, each capable of 1 thread-- had already been in the market for many many years. Software had already made the association that another thread being able to run, meant a whole other CPU to work with. That is why the OS reported it that way.

Lutris is able to front-end prefixes quite nicely, and has a GUI to prod settings fairly easily. Even a front-end to call winetricks GUI on a per-prefix basis. It can also utilize different versions of WINE, including versions of proton (and forks of proton, like Glorious Eggroll)

There is a significant difference between "multi-threading" and "Symmetrical multi processing" HT is quasi multi-threading. It allows more than one thread to be run, but only under certain, very constricting conditions. Symmetrical multi processing on the other hand, provides a coherent cache, with two or more entire processor cores that are always available. Programs that are written with the latter in mind, trying to run on the former, will run into all kinds of problems. The OS tried to present an HT capable core, as 2 cores. that was the crux of the problem. Software needed to be aware of the fact that it could not be doing two math floating point operations concurrently, or two logic operations concurrently etc.

HT is not TRUE SMT, which is the problem. It is "Kinda sorta fake SMT". The OS did not differentiate real SMT from HT. This meant that programs that actually knew how to multithread, (or OS functions that expected an ACTUAL CORE to work with) would have waitstates out the wazoo waiting for APUs to be free, and could end up with spinlock hell. That meant crashiness, instability, and other un-fun things. When it DID work, it was a nice thing. It was just that most of the time it did not work right.

This guy claims to have gotten a 1.4ghz Celeron working in his M6TBA. https://forums.tomshardware.com/threads/old-slot-1-upgrade.482801/ A lot of those BX boards could do cpus that were not 'officially' supported, which is why I mentioned adapter boards.

BX was a very good chipset, yes. It was the heart of many consumer 3rd party boards back then.

Some of those could go to early celerons on a converter board. Might be worth looking into if that one can be coaxed into it. At some point though you are going to have too many machines, and your significant other will complain. You might want to find a home for that one.