wierd_w

It would probably be better if I did this with a REAL emulator, and not DosBox. Creating the image is easy, getting it properly partitioned, formatted, and bootable is another. If you don't mind me basically pirating MS DOS 6.22, I can totes make some images for you. Hang on, I will install virtualbox, and build flat images that way.

Yes. That is why I made him some images that are nice an clean, that have more tractable allocation unit sizes. If he breaks up his collection so that "Games with larger files" live on the 1020MB D drive, and "Games with lots of itty bitty files" live on the 494MB E drive (for the 3 partition sample), he should be set I think.

Ignore the previous post-- I think I malformed the image mucking with it in dosbox, because of the byzantine way it takes the "-size" directive. Try this instead: OK, I hamfisted it at work. Here are flat disk images that are ~2gb in size, that have clean CHS geometry. 258 Cyls 255 Heads 63 Sectors (512 bytes per sector) It is partitioned with a single FAT16 partition, with a 32k cluster size. (min size for 2gb volume!) 2gb_1part.img.7z Here is one with a 510mb primary (with 8k clusters), and a 1.5gb extended dos partition containing 2 logical volumes-- the first is 1020mb in size (16k clusters), and the second is 494mb (8k clusters) 2gb_3part.img.7z And here is one with a 510mb primary (with 8k clusters), a 1.5gb extended dos partition with 3 logical volumes -- Two that are 502MB, and one that is 510MB. (all 8k clustersize) 2gb_4part.img.7z These will have: 2GB C drive --- 510MB C Drive 1020MB D Drive 494MB E Drive --- 510MB C Drive 502MB D Drive 502MB E Drive 510MB F Drive respectively.

OK, I hamfisted it at work. Here is a flat disk image that is ~2gb in size, that has a clean CHS geometry. 258 Cyls 255 Heads 63 Sectors (512 bytes per sector) It is partitioned with a single FAT16 partition, with a 32k cluster size. (min size for 2gb volume!) 2gb_1part.img.7z I will make one with extended partitions of about 512mb in size, since those can be made with 8k cluster size, but give me a bit to make that happen.

I am thinking that your disk images might not be well crafted. (Many disk image tools meant for VMs do not create images that are.. how to say... "Vintage Friendly", and tabulate out to strange geometries. I can create a better image that is flat using linux's dd command, with an exact size in bytes, that will play ball nicer.) Let me construct, partition, and format some image files for you. I will use pqmagic to create the partitions to very aggressively control cluster size for you, and force it to the minimum values. I will do that in a few hours once I get home.

There is a maximum fat16 size restriction under msdos of ~2gb, if I recall correctly. HugeFat fat16 (made with something like pqmagic) can be larger, but will have a downright obscene cluster size. For maximum compatibility, i would shoot for ~2gb fat16 volumes, with additional extended dos partitions and logical volumes as needed. Hitting the '503mb' issue sounds like CHS partitioning instead of LBA partitioning. The FAT partition type ID byte is different when CHS is used. Traditional CHS can only see up to about 503 mb. ECHS can see up to about 8GB. Any bigger and you need real LBA modes. LBA24 can see up to about 128gb. You need LBA48 to see very large modern disks. I would investigate what kind of disk controller bios / int13 routine is in the system bios, to see if echs modes are available or not. See also: https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html Incidentally, this is exactly what xt-ide project does: provide an LBA/ECHS aware INT13 handler, because XT system bios poops out at 503mb. Vintage software solutions exist, such as DiskManager from Ontrack, or EZ-Bios.

Stacker with compression off allows suballocation. It however, gobbles down a fat chunk of memory for the resident disk handler routine. It also makes working with the volume with modern tools/os very painful. Nothing modern knows how to mount or use a compressed volume file. (Even with compression off, that is still the correct term.) I still think using a lan share is the real way to go, honestly.

This is 'slack space' inefficiency of cluster size rearing its ugly head. It manifests most strongly with very small files. If you have, eg, a cluster size of 4k, and write a 512 byte file, 3.5k of space is wasted. If the MisTer supports emulating a dos capable network card, I would suggest setting up DOS networking then mounting a network share. Alternatively, you can 'try' using Stacker/Drivespace compressed volume files, which deal with small files more efficiently (but are hard to work with on modern OSes). Keep in mind that different versions of DOS also impose different maximum fixed disk size restrictions, on top of this issue.

Sad. Those are running between 60 and 120$ retail, with low inventory availability. It would be cheaper by far to add a 3<->5v dc-dc converter and a level shifter to a teensy 4.

No, teensy 4 is at microcenter, in stock. https://www.microcenter.com/product/611090/TEENSY_40_Development_Board;_ARM_Cortex-M7_at_600_MHz;_1984K_Flash;_1024K_RAM_(512K_tightly_coupled);_1K_EEPROM?storeID=191 I could drive to overlandpark and get one right now.

I like sick and sadistic things also, but dont have the real-estate to run vintage equipment. Instead, I have done "Nobody sane would EVER try to do this. So, let's do it anyway!!" type things. Just because I can. One such foray, was setting up a Netware 5 server inside dosbox (with hosted dos disk image), running on a NAS, with a VNC virtual x server. It ran about as well as you would expect. It's not like I actually had some NEED to test that-- or even for a netware server at all really--- it was one of those "I wonder if" moments.

Speak for yourself. i do enjoy tinkering, but I dont like having shit break because of my being an edgelord. I very much like reliability. when I plan builds these days, its with the '10 year realistic service life' baked in. I rode the 5yr plan version in the 90s and 2000s, and dont fancy riding it again.

Yes. There is no way to have your cake and eat it too. (There is no sensible way to have 'write permission but also read only' at the same time. If you can write files, so can malicious software.) I was not suggesting it was even possible. Only that some kinds of cake transports were better at preventing your cake getting squashed, and that a simple change in transport offers a good deal of extra protection for little extra effort.

Depends on the way you are using NFS; More recent windows boxes can host an nfs share, which the pi can mount natively with an /etc/fstab directive, for instance. The other goodies on the tipi would be quite safe this way; only the windows box would have the issue, unless you are doing very silly things on your pi. Additionally, unix permissions are a bit different than smb/windows permissions, and per-user access handled differently. Any filesharing medium will introduce risks. Both NFS and SMB are designed with a 'exists only inside a trusted, and isolated LAN' philosophy in mind. NFS at least, can be configured to only allow writes from specific local hosts, and other features, to restrict who/what can scribble where. This is not true with SMB. The 'uses a random rpc port' nature of NFS further helps isolate unwanted access from outside, due to how NAT works, but is not a foolproof method. A reverse shell exploit combined with a targeted nfs connection attempt, would permit penetration, for instance. The only real solution here is to use a COW aware filesystem (zfs or btrfs, etc), quality snapshot management, and routine backup operations, combined with very firmly enforced connection and software sanitation policies. Perhaps even incorporate a local SAN with iscsi luns, and rotating backups of the lun images inside the san. It starts looking like datacenter shit the more aggressively you seek after it. NFS sharing should ideally be safer, with only modest levels of diligence added. That was really the reason I suggested it.

Depends on the phone in question, if it supports usb modem mode or not. Most users these days are not interested in that, and so support is less and less available. If the mode is available, the phone will report itself as a usb connected serial port, and then any old telephony app will work. Otherwise, you might try pairing the phone over bluetooth, and seeing if 'handset' is a supported subclass.

Not exactly. The first one was "IBM Personal Computer" (IBM 5150), followed by the "IBM Personal Computer XT" (IBM 5160), and then "IBM Personal Computer AT" (IBM 5170). The clones are all of either the 5160 or 5170. This is because that is the revision of the IBM Bios that was reverse engineered by Phoenix Technologies, to create the clone bios that was the foundation for all the IBM compatible clones. The vast majority of them were AT clones (5170). A few were XT clones (like the first compaq portable.) Nobody was really interested in making PC clones. The correct jargon was "XT Clone" and "AT Clone." Both of those were "PC Compatible." The "system requirements" jargon was usually "IBM PC/AT or 100% compatible" or "IBM PC/XT or 100% compatible."

The malware needs the security holes in SMB to propagate. NFS has its own security holes, but they are different ones from SMB. A major obstacle to network worms using NFS, is the fact that the mount point manager uses a random port assign by default for its remote procedure calls, not a fixed one, like SMB does. You have to manually set it to a fixed one to get NFS through a firewall. (which you should never ever do. NFS is not meant to talk to the internet. Never ever ever. Without getting the RPC port from the portmapper service, the handle cannot be mounted. Without a stateful connection from the server, the client cannot access the port, because the firewall will deny-- port not yet stateful. The client is not clairvoyant, and will not know what port the portmapper has opened. NFS is pretty hard to get unsolicited access to over a firewall by default. Only when you enable fixed ports does it become vulnerable, and again, you should never, ever do that. ) https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/s2-nfs-nfs-firewall-config Unless your Tipi is already infected with root access malware (which is game over already), not running SMB at all in your home network makes you basically immune to the kinds of SMB-specific malware being discussed here. Microsoft's OSes *CAN* use NFS shares, but it takes some prodding. https://learn.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview

Tipi is a linux box. Use NFS or AFP instead.

Repacking hard disks? Reminds me of some silliness you could get up to if you managed to get your hands on old vintage SCSI enclosures. These days, those things are made of solid gold, but for awhile they were ewaste. One could in theory convert them from SCSI chain enclosures to E-SATA chain enclosures fairly simply, and then pack them to the gills with M.2 style solid state disks. Something like this SUN scsi enclosure https://www.ebay.com/itm/262947293472

Sure. You can do that quite effortlessly with a number of systems in fact. I repacked an IBM Aptiva case from the pentium II Slot-1 era with a modern i5 board for a nurse a few years back, because it was what I had on hand, and she wanted cheap. Those Aptiva cases were, amusingly, fully ATX form-factor compliant. Lots of people repack vintage 8bit systems with things like raspberry Pis, but I consider that a bit sad.

Again, it is VERY important to stress that the most modern boards cannot actually run DOS on bare metal. They really cannot. The system firmware they ship with DOES NOT contain a CSM, and thus boot directly into 32bit flat mode / protected mode. (Or even 64bit flat mode!) Computers that are about 5 years old or so, will still have a CSM, (Compatibility Support Module) baked into the UEFI firmware, which provides implementations of the oldschool BIOS service routines, and sets up the DOS interrupt vector so that realmode software can be run. They CAN run DOS on bare metal, but really modern machines cannot. This issue is very well known by groups like the FreeDOS group. http://wiki.freedos.org/wiki/index.php/UEFI Many new video cards don't properly do the full VGA register set, which is the source of the "Cannot do CGA/EGA modes" issue. The only real reason they still support that interface at all, is for the "Generic VGA adapter" driver support, so that "Something" can be displayed on the screen until you load the correct drivers. Microsoft has gotten smart, and started targeting generic VESA interfaces also (probably because modern displays cannot handle 640x480x4bit color @ 60hz) which means that VESA bios routines remain a thing. Eventually though, even those legacy trappings of the old DOS days will fall away. Probably in the next decade or so.

Before then, the VESA working group had a standardized interface for that, and their solution is still present on video cards today. That is, all the requisite software routines to switch the modes, and a standard software interface to instruct the switch, were baked into the video bios, with differing levels of featureset, based on VESA bios spec level that was targeted. That way your software could focus on JUST accessing via the VESA interfaces, and the video hardware would be jiggled by the software supplied in ROM by the manufacturer (or by a software alternative handler, supplied by a 3rd party, such as with SciTech's UniVBE/DIsplayDoctor) . This predated DirectX by quite a long time, at least 6 years.

I was a pc owner, and called them 'AT clones', because the basic architecture they were cloning/extending was the IBM PC AT. Later, after the big push into 386 flat mode, and x64 architectures, I started calling the cutoff at middle pentium systems and how the memory map was handled, 'realmode machines and 32bit optimized', and other personal parlances. These days, uefi systems with a csm that can boot dos, are so internally alien from actual realmode, calling them dos pcs is just wrong. It would be like taking a modern ARM equipped system, building a special boot resource stack for it, then running original Archimedes stuff on bare metal. The CSM is really just a software resource stack to fake having a bios present. They are also passe, and no longer being made. The detachment is complete now.

TI 99/4A has a cassette interface that can use a generic recorder. (I have found modern Onn (walmart store brand) recorders work just fine, but lack a program counter) They can also use diskette drives, but need either a special sidecar diskette drive, or a PEB for that.

Significantly less time if you blast them with 91% isopropanol first. That will dry the board VERY fast. Be advised that this will loosen/detatch any hot glue, and will loosen/detatch/dissolve some board coatings as well. (might be important if the board has hotglue stablized bodge wire, et al.) My ultrasonic cleaning unit is too small for basically anything beyond say, a floppy drive's logic board though, and I have never tried cleaning such a board that way inside it.