images

<feos> slamo Dacicus: we've had this talk in #bizhawk yesterday https://pastebin.com/aDYCUPjE
<feos> not that it makes pcemhawk happen any sooner, but it's about an important problem that hasn't been resolved yet.
<feos> what are the medium types that pcem may require for tasing, and their filetypes that it supports? does it need files-in-a-folder setups? or maybe files-in-a-folder it just packs into an image file, like jpc-rr does?
<feos> also medium combinations that may be required at once
<Dacicus> Do you mean medium types like floppy, hard disk, CD?
<Dacicus> Just looking through the menus in PCem, it apparently also supports Zip drives and tape drives.
<Dacicus> File formats: Hard disk: IMG.  Floppy: IMA, IMG, FDI.  Zip drive: IMG.  CD-ROM: ISO, CUE.  Tape: PZXI, PZX.
<Dacicus> There's also the option to use the host system's CD drive.
<feos> for determinism I think we don't want the emu to access the host itself and its devices directly, so that last option can be ignored
<Dacicus> Combos that I've personally used: HD + 1 floppy, HD + 2 floppies, HD + CD, HD + 1 floppy + CD, CD without anything else.  I don't think any of the emulated machines support 2 different CD drives, but that would have simplified some of the Tiny Core installation steps.  Basically, 1 for the TC ISO and 1 for the ISO with FP/Java/whatever dependencies.
<Dacicus> oops, CD without anything else isn't a combo
<feos> looks like we need to support arbitrary combos, but it won't have to access entire folders, only image files
<feos> do you know which of those images it can create?
<Dacicus> HD for sure.
<feos> from just a folder, right?
<Dacicus> AFAIK, PCem itself only creates blank images.  It's also got an option to create floppy images of various capacities.
<Dacicus> Floppy options range from 160kB to 2.88 MB, and then there's 100 MB (Zip).  Looks like you can save it as IMG or IMA.
<feos> looks like we'd require all the setup instructions, like with libtas, and then also put image hashes into movie
<Dacicus> For getting things from the host computer onto the disk image, I use ImDisk for floppies and some program that came with this computer for ISOs.
<feos> as xml, like the one disk builder creates
<Dacicus> yay, upload is done
<Dacicus> There's this thread on the PCem board that has info about some type of networking setup that may allow direct(?) transfers between host and guest: https://pcem-emulator.co.uk/phpBB3/viewtopic.php?f=2&t=3221
<Dacicus> IDK much about networking, so haven't tried anything like that.
<Dacicus> May not be desirable from a determinism standpoint, though.
<feos> as a preparation, will likely be fine

<slamo> feos: i had planned on streamlining the PCem setup as much as possible
<slamo> we can supply the following:
<slamo> pre-made hard drive image with freeDOS pre-installed on it. will probably start at 50 MB, with various other sizes available as needed. most of this is empty space so it will compress well
<slamo> a PCem config file, user will have to edit in their file paths for images
<slamo> and a BIOS settings file
<slamo> theoretically you can copy + paste all this stuff and boot directly into a working environment
<slamo> Nach also had a good idea about providing different setups based on the era, like having a 1985 setup, 1990 setup, etc
<Nach> I stand by it
<slamo> basically the only thing the user has to do is put their game on the hard drive
<Nach> for a ~2000 DOS setup, you probably need more like a 500MB HD for some games
<Nach> and maybe even 2GB if we eventually do Windows (is ReactOS good?)
<slamo> they could either provide hashes for the installation media + instructions, or give us info about the files like we've been doing with JPC-rr submissions
<Nach> I expect the DOS ones to all compress well
<Nach> DOS even with some mouse, audio, and CD drivers only amounts to a couple of MB
<slamo> my 100 MB freedos hard drive image compresses to about 3.5 MB
<Nach> exactly
<Nach> and if you pack on important stuff on there like various extenders, vga doctor, or whatever, it still won't get much larger
<Nach> https://web.archive.org/web/20060118061752/http://www.scitechsoft.com/products/ent/free_titles.html
<Nach> https://retrosystemsrevival.blogspot.com/2019/05/scitech-display-doctor-7.html

<feos> slamo: thanks. bios settings file is used by pcem too? or added somewhere?
<slamo> bios settings are saved for each configuration in the nvr folder
<feos> by pcem?
<slamo> yup
<feos> can it be a huge file?
<slamo> it's 1 KB
<feos> do we ever need to edit it manually?
<slamo> what do you mean by that? via a text editor?
<feos> ye
<slamo> it's gibberish if you open it in a text editor, you need to change it through pcem
<feos> good
<feos> so it's binary
<slamo> yes
<feos> and in pcem it's just options too, or you type in stuff?
<feos> I guess it's edited by actually using the guest machine
<slamo> you actually do it through emulation
<slamo> by pressing DEL at the POST screen
<feos> sounds like how emulators work with sram
<slamo> like i showed in the tutorial
<feos> that file is a part of emulation itself, and on actual machine it won't appear from editing bios?
<slamo> right, it doesn't manifest itself as a file within the disk image
<slamo> if you get rid of the nvr file, it just uses BIOS defaults
<feos> I mean if I edit host bios, that file isn't present on the host machine in any form?
<slamo> right
<feos> like, that file is just a simulation
<slamo> the file only exists on your real computer
<feos> sounds like sram indeed
<slamo> pretty much
<slamo> the only things it's used for here are detecting storage media and boot order, but those are important things
<feos> when the game writes to hdd, does that edit the file or stores the diff separately?
<slamo> it shouldn't, let me make sure
<feos> or floppy
<slamo> looks like it edits the nvr file every time the system is shut down? might be clock related
<slamo> we don't have to worry about this anyway since libtas doesn't change the original files
<slamo> although, when you're installing your game outside of libtas the nvr file will change, so everyone's will be slightly different
<slamo> different from the one we supply i mean
<slamo> unknown if this will affect sync at all
<slamo> if it does, we just have them supply theirs
<feos> I mean if this ever gets into hawk, it may not be able to intercept the core writing to files on disk directly
<feos> mame and fs-uae store image diffs separately for example
<slamo> for casual use that's fine, but obviously for TASing we want the original files to stay the same
<feos> yup