wierd_w

Its used a lot (*A LOT*) in SAN environments. iSCSI and pals use LUNs for the devices they control. Many storage controller head units will parcel out virtual volumes as iSCSI LUNs. Virtual servers tend to use this kind of arrangement frequently-- where a SAN provides multi-path, redundant/fault-tolerant iSCSI over TCP, which then get mounted by something like ESX or VMware, and each virtual server snacks down a LUN. It used to be used more frequently by end users in the 90s, when external SCSI chains were standard options on several Mac models. Each adapter is referred to as the host bus adapter, or HBA. Each HBA has 7 LUN IDs it can present on each of its ports. Each disk on that port needs a unique ID.

inches?? Drawing was totally in mm, and I set my CAD export as mm... will double check. Yup.. Modeled in mm, like the drawing. Or do you mean the measurements made on the PEB's geometry above? The original part was designed by US engineers, and so everything should come out to even multiples of 1/16 (or 1/32)". I will include both sets of numbers when I make proper prints of the drawings. For now, I am still in the data collection phase.

Here we are... Prototype Genesis slot spacer. Should cover the bottom 2 finger widths (4 pins) of the slot, wrapping around the outer perimeter of the slot for alignment. Print with the flat wall side down so that there is no bridging. genesis_slot_spacer.stl

If you give me some dimensions to work with, I can whip up such a spacer model right here and now.

Genesis slot huh.. what if a 3d printed spacer was inserted? Then it would be impossible to insert the cards wrong, even with the longer slot...

That's unfortunate. FC slots are inexpensive. Often though, thicker cards can be inserted, since there is give in the fingers. The width of gap between the plastic lands inside are the major hurdle there.

Since it was mentioned--- Is the pitch on the 60pin PEB slot 2.5mm? If so, then would it be possible to source nintendo/famicom slots? https://www.aliexpress.com/i/32827561249.html

Replica PEB was the direction I was going as well. If the card slot connectors are a standard pitch, sourcing them shouldn't be "THAT" hard I don't think... For RF Shielding, I was going to print/assemble the outer housing plastic, then liberally spray the inside with conductive paint. (several layers) Since the cards that go into a PEB have that plastic protective housing on them (for commercially made originals anyway), getting the spacing, and retention system right is an absolute must. That means "Faithful Reproduction". For power, I was going to go hunting for the correct rail voltages when shopping for a supply. The hardest part (for me) I think, is gonna be raising those sheet metal bosses that the inner cage sheet metal retainer rests on. I might end up printing plastic feet to hug tall brass stand-offs instead.

With full dimensions, I could make a full size flat pattern print (since I have a large format printer. 😉)), then I could use spray adhesive to stick it to the sheet metal, cut it, and manually bend it with some forms. With access to dimensions of the plastic outer housing, I can design modular 3D printed "Snap together" parts. AND-- with the drawings and such made available, other people could do the same.

Success on getting the so called "XP ONLY" audio hardware to turn on in win98. It's just a little INF file doctoring. Woo. Initial testing shows that (at least while windows is running...) It is able to simulate "enough" of a soundblaster for wave audio to work, and it routes MPU401 based midi through the generic windows wavetable device. I think I have an MT32 emulator floating around that might be installable as well. Unsure how it works in pure dos mode though. Obviously the midi handler wont be there...

I2C on Ti99/4A http://www.stuartconner.me.uk/ti/ti.htm#i2c_interface SDCard in SPI mode http://elm-chan.org/docs/mmc/mmc_e.html#spimode Already been done; Just needs storage stack. Or did you mean i2C on the cassette header? (I doubt you could do that reliably...) Wait... How fast can you joggle the tape-hold signal? If you use tape-hold as D0, the audio signal output as the SCLK, and the audio input as D1....

One that tends to get real bitchy is wizardry 7. Since it needs a hackery TSR to jiggerize its memory (otherwise it asks you to fumble for a manual that you really dont need for any other reason), the amount of low memory available to it is diminished. Getting every scrap free is important. Some others that I remember from my past are Xwing and TieFighter. I am actually quite pleased with getting this thing as squeezed down as I have though.

Another setback today. I erroneously thought this thing had ESS audio. (Which has DOS drivers). It does not. It's a SigmaTel AC'97 Stac 97xx. (which apparently is also a realtek, and a few others... same actual hardware from what I can gather.) After much digging I located a win9x driver, but it is a VXD based one. (no realmode support.) It is claimed this is an XP-Only sound chip... We'll see how these ancient 9x drivers work on it. I am going to backup the dos partition I have to date; I might get it an OPL3LPT if I really want pure DOS. I will see if the VXD driver is able to simulate SB16 hardware interfaces first. If so, win98 might be what is called in to save the day.

17k used is pretty good actually. Some games actually complain if they have more than 620k available.

Bought the last one. (Getting fed up waiting for my Tipi...)

given the shared grounding between the mic and speaker, I don't think you could do very good fidelity on bidirectional transfers without adding some diodes. It would be neat to see the cassette port abused as a modem (if you could turn the sound off to prevent it on the line), or to get the thing to make arbitrary audio as a PCM device... but I doubt either of those is really possible. ** IF we are going to go crazy and radical though, I would like to see a radical overhaul of the "cassette" system that leverages the joystick port for its 2-wire i2c capabilities. This could either be used to straight up talk directly with an SDCard (which supports i2c according to the spec!), or be used to control a more sophisticated tape deck, to give the cassette loader random access capabilities.

OK, Switching to shsucdx and vide_cdd.sys seems to have solved a good deal of this pain. Together they eat 11k of UMB, which fits nicely in the video adapter ram area UMB. Sadly, to answer my own question, JEMM does NOT forcibly remap the included addresses!! I found a quirky little thing called dosmax, which is able to move parts of the command interpreter and dos environment into upper memory. Together, now the total conventional used is 17k. I think that's the best I can get.

I have tested a 256gb SDcard in my Wii-U. Works fine. I use that with the vWii to do Wii Backups & homebrew, and use the ext USB drive for Wii-U backups. The original Wii could not handle a card that big.

If you load up the Wii with the homebrew channel, it also can function as a low-end dosbox. Dosbox for the console is surprisingly 486-like, and it also supports USB keyboards and mice. (The WiiMote will also function as a mouse if you want.) It beats having a clunky computer at your entertainment center. Attach a wireless USB keyboard, and it's classic game gold. (The classic controller is supported as a joystick too.) The CPU inside the Wii is not really powerful enough to emulate anything beefier than a 486DX-2 50, with OPL synth-- but that's what most old DOS systems had in the period anyway. Sadly no network function. It can do NES, SNES, GENESIS, and pals too with the appropriate emulators. It's a very robust little system, despite its 480P max resolution. It's a shame that the Wii-u did not get the same level of attention for homebrew that the Wii did. I would have loved to use an updated dosbox there. (Since I replaced my Wii with a Wii-U.) It feels kinda like being cheated to have that CPU horsepower not getting used, while struggling to have playable speeds on vintage FPS games. (Though, that DOES re-create the vintage experience.......)

A NiMH charger can charge NiCd, but not the other way around, or so I am reading. Depending on exactly 'how' they are charging the batteries, (perhaps drop a charge controller IC on?), a NiMH replacement could be done.

So, some time ago I had a fujitsu lifebook E2010 dropped into my lap as a freebie. This is a PIII class laptop with 1gb of RAM, a 300ishGB HDD, ATI mobile graphics, with a rather strange combination of ALI and ATI chipsets. It boasts an ESS AudioDrive based sound device, which more or less emulates a SB16. I had decided to set this thing up with "hardened" dos 6.22 and win98se deploys, with a winXP deploy along side. In therory, this would let it run DOS, win9X and XP era classic PC games, but I have since come to question this... As I dug into the nitty gritty, problems started emerging. I am currently fighting the MS-DOS setup phase, and the way this thing's adapter region is laid out is just.... UGH. Whoever laid this out needs to be killed slowly. 1) The video bios is huge. It eats up a whole 64k of adapter rom, just by itself. 2) There is a worthless PXE bios option rom (4kb in size) that the bios wont let you disable. It sits right after the video bios. Combined with the video bios's area, this range is from C000-CFFF 3) UMBPCI says the PCI chipset is unknown (because it is a strange frankenstien of ALI and ATI chips.) As such, it wont enable hardware UMBs. It does however, identify an area that can be turned on. 4) The bios consumes the bottom half of the adapter rom-- ANOTHER 64k block!! (E000-EFFFF) The absolute "Best" I have been able to coax out of this, is to include the monochrome adapter RAM region (B7FF-BFFF), the PXE bios's area (Since it is not needed at all! This forces EMM386 to remap the region it occupied), and FORCE placement of the EMS Page frame at D000 (after forcing EMM386 to include CC00-DFFF). (otherwise, EMM386 insists it cannot place the page frame!! This is because the PCI set wants to hang onto this area for reasons that escape me. There is NOTHING mapped there! Without the include statement, EMM386 insists that there is an option rom but there totally isn't one there.) I am used to getting much more UMB area than this thing gives me. This gives me a small bit of UMB in the adapter RAM area, which is barely enough for MSCDEX, a tiny 4kb sliver right after the video bios, and another 4kb sliver just after the page frame to use as UMB areas. Aside from switching to SHSUCDX, and something smaller than the OAKCDROM.SYS I am using, this seems to be the best I can get... This.. Disappoints me. Does anyone know if JEMM386 can forcibly remap adapter region like EMM386 can? That might be an option here, since EMM386 is a hog, and UMBs are in short supply, and this thing's adapter region is wonky.

Yeah.. If both are using port 9640, then the one that has the port forwarding rule pointing to it will get all the outside traffic. You need to change the active port on one of them, then put two port forward rules. One for the geneve driven one, and one for the 99/4A driven one. Supplemental reading on NAT routing should clear all this up. https://computer.howstuffworks.com/nat.htm The short version: You have a private network living inside your house, which the internet cannot see. There is a public network outside your house (the internet), that your home network can connect to, via a broker. (your NAT router.) From the internet side, there is a single device. The NAT router. The NAT router is an intelligent device, and it keeps a table of which private IPs originate a connection to what public IPs, on what ports. It makes use of its extended port area to handle additional requests. (Such as two or more private addresses using a port 80 request on a website). The NAT router will assign one port number to the first device, and another to the second, and that is how it handles both sessions. However, since all connections made this way must originate inside the private network before transmissions can be sent back through, this makes running a server impossible. Enter Port Forwarding. Port forwarding makes a permanent port->PrivateIP:port assocation, and is a 1:1 relationship. If you say port 9640 points at private IP 191.168.0.4's port 9640, that is ALWAYS where traffic delivered to the NAT router will be redirected to. 192.168.0.4's port 9540. Always. You want to either set up a fault tolerance configuration (which will be unique to your situation), so that one unit will handle traffic unless it gets too busy, then the other will. OR-- you want to create another port forwarding rule at the router to redirect another NAT facing port the IP:port of the second device. EG, a rule like port 9641 ->192.168.0.5:9640 Then, from the internet, you would probe port 9640 for the first device, and probe 9641 and get the second device. NOW-- servers that handle multiple incomming connections tend to use a PORT RANGE-- rather than a fixed port. They have a single port used to negotiate a session, but still use a range of ports to direct the connecting device to get a unique session on. See for example, passiv FTP. Incomming connection happens on port 21, like expected. The server also has a range of additional ports it has earmarked for its use. It tells the incomming connection to reconnect on one of those other ports, and specifies which one. The connecting system does that, and then lives on the new connection. this frees port 21 for another incomming handshake. To handle that, you need to set up port forwarding RANGES to the hosting IP in your router. Not all routers support ranges. (You will have to instead create a bunch of manual single forward rules for each port in the range if that is true. Nasty.)

That's... Enormous. Now I wonder if we could get adamantyr to rejigger his memory handling on his CRPG to work with this... FG99s are a lot more plentiful than SAMS cards.

OK, another use case for a virtual minimem+page (with better DSR) on a finalgrom: The most recent FG firmware supports saving the minimem memory to the SDCard. (Important!) Base system with no PEB or PEB-alike; User would REALLY like to use some disk based games, but simply cannot get one (PEB like solution). (These things occasionally become available, but waiting can be a long time. FG99s appear more regularly on places like Ebay.) Since this would require a rewrite of the DSR in the first place, (and the FG allows paging of the ROM area as well), a fully proper ramdisk that gives a DSK1 device, coupled with the "save minimem memory" support, == FG99 "now a 'disk based' game storage option" If you combine that with some way to get programs files off cassette reads (eg, binary ones, not just basic files) and save them to arbitrary file names, a slow but laborious process to load the "enhanced minimem" with disk based games becomes possible. (of course, they could just inject the necessary data into the FG99 rom image instead. :))

I would say the PIII is probably good for basically all cases. Old enough to still have actual real-mode support. New enough to have PCI based UMBs, so you can have maximally free conventional memory. Also new enough to put enough memory in to do a "hardened" 9X install. (Use syslinux boot loader with the memdisk "kernel" image. Uses 1kb of low memory to hook INT13 disk interface, and the memory free register used by XMS drivers. Provides very nice, and high capacity ram disks loaded from persistent storage at boot time, in a multiboot menu. Set up a 9x install in a 512mb FAT16 partition, turn on drivespace3, turn on ultrapack on everything, defragment it, then image it. Use that as the image used by memdisk. Your 9x deploy is now "very hard" to break, because each boot is a fresh, clean install experience. Similar can be done for the system partition for a real DOS 6.22 image, with both 9x and Dos not seeing each other's volumes. I can give much more detailed instructions if you need them. There are also ways to get 9x to load out of a ramdisk created by something like XMSDISK by exploiting the undocumented /mount option for scandisk... but the memdisk solution is superior in basically every way.)