wierd_w

Disk space is cheap. BSAVE and BLOAD can be used on arbitrary data contained inside of arrays. This allows it to be used with custom types, etc, and thus can be used for slow disk paging of entire memory structures. 640k is only really limiting in terms of the size of the array. Even then, it is possible to directly hook and prod at XMS memory, if it is available, by writing to the appropriate handlers. (Initiating calls with io requests, with data in registers, et al.) What qbasic lacks is an efficient bulk memory copy routine. Writing one as an assembler stub, then executing it after pulling it into memory, and wrapping that invocation in a sub statement should do the trick though.

Renaissance Festival and Steampunk COSPLAY. Only with vintage nerd clothes, and anachronistic home computers. You're welcome.

After putting the mrchromebox uefi firmware, yes. Out of the box, no. You would need to put it into 'developer mode', then run the firmware installer script from a crosh shell. After that, it would have coreboot uefi, and be able to run any uefi capable OS. (Windows 10+ included, but may need stuff from coolstar to run properly. Win7 is not truly uefi. Needs a CSM, and coreboot from mrchromebox does not have one.) You would need to open the lid and remove the write protect screw before flashing with the install script. It would basically be a 'fully FOSSed' NUC after that. That particular one is reasonably upgradable even. Note that it has an NGFF SSD, and SODIMM RAM.

That is also surprisingly something that got only the tiniest love on the PC, despite its graphics hardware supporting software provided fonts since nearly the beginning. Everyone just used the rom fonts, and that was all, unless they had specific need otherwise.

If they want a pretty set-top box, Get and recondition (with mrchromebox uefi) a chromeBox. Its about the same thing as a NUC, but much less expensive. Here's one on fleabay for 70$. I7 with 8gb ram. MORE than beefy enough. They could do all the way up to wii/wii-u on that. EmulationStation would work fine.

'More capable' in terms of synthesizable circuit space, not speed. It's not just the cpu that needs implemented with HDL, it's also all the bespoke stuff, like Agnus and pals on an Amiga, or the MMU and pals on classic macs.

Cheaper! If you dont mind a little ear pulling, you can transform a weak-kneed chromebook into a very nice emulation platform. 100$ pricepoint is VERY doable. (check out mrchromebox.tech, for details! Getting a "Real" UEFI firmware on that 100$ POS is quite doable!) It is more than powerful enough to doe UAE, ST emulation, DosBox, and pals. EmulationStation on it would be quite doable.

I see! Is there a reason they stayed with the cyclone 3, rather than the more capable cyclone 5? They could have kneecapped mister if they had done the latter..

Just to clarify, the 1.5 version does NOT require a DE10-Nano? Getting a mist off fleabay was pricy but possible, but the DE10-Nano was exorbitantly expensive. If they integrated a suitable fpga onto the 1.5 mister, so it no longer needs one, the site does not say so.

It apparently is a synchronizing device, for synchronizing serial data streams. http://www.muzines.co.uk/articles/the-answer-is-smpl/1420

Naw. Vacuum tubes can be made with darkage tech. Lampworked glass and copper would work fine.

I have a vintage parallel port zip100 which still works fine, but that was a 'new in box' purchase from 30 years ago. Mine has the connector for 'not really scsi' so it could live quite a few places, in theory. It's slow as hell, but was useful awhile back for getting stuff on my dos gaming retro laptop. Otherwise no. I dont collect. I have considered the amusing chic of rebuilding some apple or sun scsi enclosures and slapping them on a nas box, but decided that's a waste of vintage gear.

Yes. Dosmax 2.1 can be nabbed from here. https://software-archive.tifan.la/cndos-new-dos-16-years-collection/soft/doswared/

Dosbox has an ARM port. You would need something like that. Retropi has support for dosbox, iirc. Games themselves? Doom was open sourced years ago, but others? You'll have to look for them.

From what I was reading use-umbs is the proper tool, and can accept different ranges, despite what I read in the readme. I did some digging. This core emulates a lo-tech 2mb ems board, with a pageframe address of a000. MSD is not properly detecting a ROM at EC00, according to what I am reading. Probably is not setting the memory read only. The author suggests the following in this post. FILES=40 BUFFERS = 30 DOS = HIGH, UMB DEVICE=C:\UTIL\USE!UMBS.SYS C000-EC00 DEVICE=C:\UTIL\DOSMAX\DOSMAX.EXE /R+ /N+ /P- DEVICEHIGH=C:\UTIL\LTEMM.EXE /p:A000 /x /n SHELL=C:\UTIL\DOSMAX\SHELLMAX.COM C:\COMMAND.COM C:\ /E:256 /P It may be possible to enable more upper memory, but I need to know how big the xt-ide bios at EC00 is. MSD should detect the option rom in the other memory viewer pages, and say how large it is. I think it's "memory browser" or something like that. Been awhile. This is because option roms contain a magic header byte sequence identifying the option rom and its size, and MSD is designed to scan for this, even if the memory is writable. Normally, I would test and experiment myself, but the de10-nano needed to build a mister is too expensive.

You need an UMB enabler. Himem.sys does not do it alone. Himem.sys is reporting 32mb free XMS. This is clearly not the pc/xt mister core, because xms would not be available. If this is the AT core, try emm386?

Depends... Cellulose has a long life but not infinite. Plastics outgas, and the plasticiser degrades, but if kept in a hermetic environment, that process stops. Properly stored, it's kind of a tossup.

There were also 'turbo AT' cards, that put a bigger cpu on the ISA bus, and used a ribbon cable to the cpu socket to drive the rest of the memory bus. Things like the Intel InBoard, and various others. Apparently, it's possible to stack such upgrades... https://forum.vcfed.org/index.php?threads/running-486-on-inboard-386.47554/

I am a fan of Direct Access 5. It DOES work on XTs. It supports submenus. (I have never found a functional bottom to how deep it can nest.) https://winworldpc.com/product/direct-access/5x (I use it to get around the restrictions on the free version of adosbox on android. It limits to one application-- phht-- OK, I will set up DA5, and then pick from there!) It has a few nice features, in that it returns to the menu once you quit your game/application.

You have the entire adapter rom region free, and backed with RAM! Consider a different enabler that accepts an argument for the regions to enable. The one you are driving now has a readme saying you have to manually patch the program to change the target region. It looks like you could use between C000 and EBFF. That's a big area. The core does not emulate extended memory, but some old games can use expanded (ems) memory. There's a DOS driver that can live in upper memory that can provide it via what is essentially a swapfile. Found it. https://www.vogonsdrivers.com/getfile.php?fileid=851&menustate=0 EMS memory would be 'slow', because it is fetched from disk, but games that use it would have it available. (It's normally provided by a hardware ram card with a mapper chip) DOSMAX would be a good choice here also, since we have ample ram-backed area to work with. It can load files, buffers, fcbs, and the command interpreter into UMB. You can realistically have over 600k free.

Dosmax works on AT class also! I am just wondering if we can get more than the tiny bit of ram at cc00-ccff. I need to see what the map looks like with nothing loaded.

This is an XT class machine, so it wont have more than 640k. (though it looks like you are using a memory manager to enable hardware UMBs in the adapter region... So we can TRY to maximize what is enabled/used. MSD with nothing loaded, not even the enabler, will let me see what areas are consumed by ROM.) Normally, there might only be some small benefit from altering the load order, since XTs normally cannot load anything high. In this case though... Yeah, let's see what we have to work with, and what we can get it to do. If this is a 386 class machine with extended memory, then I need to see what your memory map looks like with nothing loaded. DOS 6.22 comes with a utility called MSD. It will let me see what I need to see. Since this is with a MiSTer, take a screenshot with it running showing the memory map for me, and post it here, then we can discuss what memory managers you want to use, and how to prod it good.

Sweet! Merry christmas indeed!

OK, I will make some. These are not perfect sizes, because of a bug in DOS that prevents full use of 256 heads and or 1024 cylinders, for sizes. Closest matches provided, for max compatibility. They should be bootable with minimal system DOS 6.22. They were created with dosbox, because it is just faster than manually prodding vmdk files for virtualbox, but I did test booting them with dosbox. 254.75mb (267125760 bytes) disk 256mb.img.7z Single partition, 4k cluster 512 bytes/sector 1023 cylinders 255 heads 2 sectors/track 510mb (536870912 bytes) disk: 512mb.img.7z Single partition, 8k cluster 512 bytes/sector 1023 cylinders 255 heads 4 sectors/track 1019mb (1068503040 bytes) disk: 1024mb.img.7z Single partition, 16k cluster 512 bytes/sector 1023 cylinders 255 heads 8 sectors/track

OK. Here is a booting version of that 3 partition image. Has Dos 6.22 installed, nothing else. Same partition structure. 2gb_3part.img.7z You can probably just fix the image you have by running FDISK /MBR on it, however. Basically, the disk image lacks a boot loader in sector 0, since it was a 0-filled image. (I had to re-learn how to build VMDK header/descriptor files for flat images, so that I could feed it to virtualbox! LOL! Anyway, the issue seems to have been the missing MBR code. Running the magic fdisk command with that switch should fix it.)