Posted at 21:10 on March 29th, 2020 | Quote | Edit | Delete | |
Member Zombie Gumby Posts: 3879 | Ok, guys, so let's continue here. As is evident from the topic and earlier discussions on IRC and TDC board we are trying to come up with best ways to produce 86F images from any other format in one convenient go. At this point it's not entirely impossible but the current solutions have proved to be unreliable. We still need a universal converter preferably with a quick and simplified routine for 86F production akin to HxC. Let's unite our forces. All thoughts, suggestions and questions are welcome. Here's the latest 86F v2.14 spec just in case: Code: 00000000: Magic 4 bytes ("86BF") 00000004: Minor version (0E) 00000005: Major version (02) 00000006: Disk flags (16-bit) Bit 0 Has surface description data (1 = yes, 0 = no) This data indicates if the corresponding bit on the FM/MFM encoded surface is a normal bit or a special bit (weak bit or hole, depending on the other bit): 0 = The corresponding FM/MFM encoded surface bit is normal 1 = The corresponding FM/MFM encoded surface bit is either a weak bit or a hole: Corresponding FM/MFM encoded bit is 0: Hole (noise on read, not overwritable) Corresponding FM/MFM encoded bit is 1: Weak bit (noise on read, overwritable) Bits 2, 1 Hole (3 = ED + 2000 kbps, 2 = ED, 1 = HD, 0 = DD) Bit 3 Sides (1 = 2 sides, 0 = 1 side) Bit 4 Write protect (1 = yes, 0 = no) Bits 6, 5 RPM slowdown (3 = 2%, 2 = 1.5%, 1 = 1%, 0 = 0%) Bit 7 Bitcell mode (1 = Extra bitcells count specified after disk flags, 0 = No extra bitcells) The maximum number of extra bitcells is 1024 (which after decoding translates to 64 bytes) Bit 8 Disk type (1 = Zoned, 0 = Fixed RPM) Bits 10, 9 Zone type (3 = Commodore 64 zoned, 2 = Apple zoned, 1 = Pre-Apple zoned #2, 0 = Pre-Apple zoned #1) Bit 11 Data and surface bits are stored in reverse byte endianness Bit 12 If bits 6, 5 are not 0, they specify % of speedup instead of slowdown; If bits 6, 5 are 0, and bit 7 is 1, the extra bitcell count specifies the entire bitcell count Bit 13 Revolutions (0 = one revolution, 1 track has 16-bit number of revolutions) 00000008: Offsets of tracks Note that thick-track (eg. 360k) disks will have (tracks * 2) tracks, with each pair of tracks being identical to each other. Each side of each track is stored as its own track, in order (so, track 0 side 0, track 0 side 1, track 1 side 0, track 1 side 0, etc.). The table of the offsets of tracks is 2048 bytes long, each track offset is an unigned 32-bit integer. An offset of 00000000 indicates the track is not present in the file. As an example, an 86F representing a disk with 80 thin tracks and 2 sides per track, where all the tracks are present in the file, would have the first 160 offsets filled in, same for a disk with 40 thick tracks and 2 sides. Same with only 1 side but only the offsets at 0000000, 0000008, etc. (so every second offset) would be filled in. Track offset + 00000000: Track flags (16-bit) Bits 7, 6, 5 RPM 000 = 300 rpm 001 = 360 rpm Bits 4, 3 Encoding 00 = FM 01 = MFM 10 = M2FM 11 = GCR Bits 2, 1, 0 Bit rate, if encoding is MFM: 000 = 500 kbps 001 = 300 kbps 010 = 250 kbps 011 = 1000 kbps 101 = 2000 kbps If encoding is FM, the bit rate is half that. If extra bitcell count is present: Track offset + 00000002: Extra (or total, depending on disk flags) bit cells count (32-bit) If this specifies extra bit cells rather than total, it is a signed integer, and when negative, makes the track smaller. Track offset + 00000006: Bit cell where index hole is (32-bit) Track offset + 0000000A: FM/MFM/M2FM/GCR-encoded data (track length bytes) Track offset + 0000000A + track length: Surface description data if present (track length bytes) Else: Track offset + 00000002: Bit cell where index hole is (32-bit) Track offset + 00000006: FM/MFM/M2FM/GCR-encoded data (track length bytes) Track offset + 00000006 + track length: Surface description data if present (track length bytes) If this is a multi-revolution 86F, then track offset + 00000004 has a 16-bit number of track revolutions, everything after it is moved ahead by 2 bytes, and FM/MFM/M2FM/GCR-encoded data appears (number of revolutions) times rather than once, while surface decription data, if present, only appears once. Track lengths: Hole 0 (DD) or 1 (HD): 2.0% RPM slowdown: 12750 words 1.5% RPM slowdown: 12687 words 1.0% RPM slowdown: 12625 words 0.0% RPM slowdown/speedup: 12500 words 1.0% RPM speedup : 12376 words 1.5% RPM speedup : 12315 words 2.0% RPM speedup : 12254 words Hole 2 (ED): 2.0% RPM slowdown: 25250 words 1.5% RPM slowdown: 25375 words 1.0% RPM slowdown: 25250 words 0.0% RPM slowdown/speedup: 25000 words 1.0% RPM speedup : 24752 words 1.5% RPM speedup : 24630 words 2.0% RPM speedup : 24509 words Hole 3 (ED + 2000 kbps): 2.0% RPM slowdown: 51000 words 1.5% RPM slowdown: 50750 words 1.0% RPM slowdown: 50500 words 0.0% RPM slowdown/speedup: 50000 words 1.0% RPM speedup : 49504 words 1.5% RPM speedup : 49261 words 2.0% RPM speedup : 49019 words 1 word = 2 bytes (so 16 bits) If extra bit cells count is present and it indicates extra bit cells count: Track length = (Track length << 4) + Extra bitcells count If (Track length & 15) Track length + (Track length >> 4) + 1 Else Track length + (Track length >> 4) Track length in these formulae is taken from the tables above. If extra bit cells count is present and it indicates total bit cells count, then the total bit cells count become the track length. On a sidenote, if you are wondering why the subject was moved here then please address this question to Trixter. I don't think I'm competent enough to answer that. ----- [i]Cheer up! Remember the less you have, the more there is to get.[/i] ----- Edited by Moebius at 00:01 on March 30th, 2020 |
Posted at 17:27 on April 4th, 2020 | Quote | Edit | Delete | |
Member Baby Gumby Posts: 7 | Is 86F really the best floppy image format available? It would be nice to have one format accepted as a standard one, but I think it should then be universal enough to support all (well, as many as possible) types of copy protection AND be accepted by as many emulators as possible. For now, simple IMA/IMG (or, 180/360/720 etc., in Trixter's latest Disk2Img) is the only common format, supported by DOSBox, VirtualPC, PCem etc. Of course, it has one serious flaw of not supporting the copy protection. Still, it could be widely used just as ISO is used for CD-ROM images that do not have CD Audio tracks or protection. And as for protection... There are too many formats and way too many types of disk-based copy protection! Is there a format that can support them all, both in emulators and in writing back to disks?.. I think we should first make a list or table of protection types, showing the image formats and emulators that can handle them There is a list by Great Hierophant, but it is surely incomplete. I have made a small table of my own collection, but that's just a drop in the ocean... |
Posted at 03:36 on April 5th, 2020 | Quote | Edit | Delete | |
Member Zombie Gumby Posts: 3879 | Quote: Is 86F really the best floppy image format available? Not sure about preservation as obviously we have yet to sort out conversion as well as production issues, but I certainly do believe it's the best candidate for emulation at the very least. It's light, clean, precise and fast compared to flux dumps, which must be transcoded to "edible" format first. You may not see the difference on modern machines, but I do believe this process should take a few more seconds of your life prior to actual execution. Quote: It would be nice to have one format accepted as a standard one, but I think it should then be universal enough to support all (well, as many as possible) types of copy protection AND be accepted by as many emulators as possible. I'm not against it per se, but I believe apart from "proprietary" ambitions on part of emulator devs there are plenty of other obstacles and the underlying factors are too subtle for us to speculate about them so frivolously. For instance, 86box assumes you have a real drive set up in BIOS, whereas PCE will mostly ignore it and use some automated script, hence the "hacky" nature of PSI format. Is it good or bad? Sounds like a matter of preference, but personally, I'm all for correct and genuine execution if we are to fanatically embrace copy protection, otherwise I can hardly draw a distinction between that and cracked loaders. Anyway, I reckon up till now Teledisk has been regarded as a universal format for running physically protected games across different emulators, only it was never meant to do that. Its algorithm was aimed to work with so-called "oddball" formats, where copy protection is more of a side-effect. I believe I got this information directly from its creator (Dave Dunfield) on VOGONS. Quote: And as for protection... There are too many formats and way too many types of disk-based copy protection! Is there a format that can support them all, both in emulators and in writing back to disks?. I'm not sure about Teledisk, I've heard people say it can't really chew on 'weak bits', but 9 times out of 10 it does the job just fine. 86box should perform even better. For convenience sake we should draw a line between emulation and preservation (stream/flux) formats and not really mix them. A lot of people say "there should be a support for kryoflux dumps" but I honestly don't get the sentiment. First off, they are huge. Secondly, it's just a raw magnetic imprint with a lot of junk in it, emulators shouldn't work with that by definition. They are heavy and require a lot of filtering. Besides, making them writable in emulator is another great challenge which isn't really worth a dime. Therefore, the split between emulation and preservation is perfectly justified in my opinion. When it comes to emulation alone everything aside from TD0, PSI and 86F should be disregarded. Likewise, we should ignore everything apart from KF, SCP and TC if it's all about preservation. The two are interconnected nonetheless, and you can't produce the former without the latter. And none of the each group will ever go I'm afraid as all of them have their pros and cons, which depending on user needs can be optional. As for making PSI or 86F available for non-native emulators, I personally wouldn't do that to avoid confusion. Quote: I think we should first make a list or table of protection types, showing the image formats and emulators that can handle them We already have one here and it's constantly being updated. As for the wiki, I have already stipulated the conditions Quote: I have made a small table of my own collection, but that's just a drop in the ocean... Thanks for that, I will add a few missing titles to our list. ----- [i]Cheer up! Remember the less you have, the more there is to get.[/i] ----- Edited by Moebius at 05:45 on April 5th, 2020 |
Posted at 05:46 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | 0: And as for protection... There are too many formats and way too many types of disk-based copy protection! Is there a format that can support them all, both in emulators and in writing back to disks?.. There are a lot of formats because each formats have shortcomings: - PCE's PSI makes the mistake of assuming the cylinder and head parts of the sector ID always correspond to the physical cylinder and head they are located on, but 2M and IBM XDF formats prove that assumption wrong; - Both TD0 and PCE's PSI I believe don't store the data rate or encoding anywhere which makes it impossible to determine that stuff other than by guessing based on the floppy type field, and even that's per disk while each side of each track should have its own; - HxC MFM stores data rate and RPM stores data rate and RPM information, but again per disk while each side of track should have its own, and it also stores the amount of bytes in each track instead of the amount of bitcells, which means that if a track wraps around in the middle of a sector (and I've had cases of that already), you'll get CRC errors when trying to read that sector; - IMD officially doesn't stor one of the sector ID fields (I forgot which now) but there's propopsal to add it that my emulator (86Box) implements; - HxC HFE is unstable (as in, unfinished and subject to constant change) and I am therefore wary of using it; - FDI stream and KryoFlux are good but they have the problem that you can't really make them writable in an emulator, and there's copy-protected software that requires being able to write to the floppy, sometimes even as part of the copy protection itself (eg. early Ashton-Tate software that writes to a particular sector to verify that the first 272 or so bytes of it are not writable (are physical holes)). I have tried to address the shortcomings in 86F (though I have yet to implement 86F v2.14's multi-revolution support in the emulator as I've been busy doing other things), but 86F could have its own shortcomings I'm not aware of. And I just realized that I could make the multi-revolution support even more powerful, I'll be releasing an updated 86F v2.14 specification soon. |
Posted at 10:04 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | Quote: There are a lot of formats because each formats have shortcomings: - PCE's PSI makes the mistake of assuming the cylinder and head parts of the sector ID always correspond to the physical cylinder and head they are located on, but 2M and IBM XDF formats prove that assumption wrong; It doesn't. PSI can store a complete 4 byte MFM ID for every sector. Quote: - Both TD0 and PCE's PSI I believe don't store the data rate or encoding anywhere which makes it impossible to determine that stuff other than by guessing based on the floppy type field, and even that's per disk while each side of each track should have its own; PSI stores both the sector encoding and data rate per sector. Anyway, the format you want to compare 86F to is PRI. This is a universal raw bit image format. In PCE it's the default format for all emulators except the IBM PC (and that is planned, too, I just haven't gotten around to it yet). I have looked at a lot of copy protection schemes used on the IBM PC, Atari ST and Macintosh and so far I haven't come across one that PRI can't handle. I have looked into adding 86F read and write support to the pri utility included in PCE, but I find the format to be extremely (and unnecessarily) complex. Here are some thoughts:
|
Posted at 10:12 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | 0: It doesn't. PSI can store a complete 4 byte MFM ID for every sector. Well, then I must have been looking at an outdated PSI specification. If you could link me to the latest one, it would be nice. Quote: The weak bit mask is enabled for the whole image. It would be better to enable it on a per track basis. That's actually a good idea, and I'm going to look into it. Quote: The handling of bit rates, RPM and track lengths is too complicated. Why not simply store a bit rate and a track length in bits for every track and forget about RPM slowdowns, zones and hardcoded track lengths? RPM slowdown is needed to store formats that don't fit at perfect RPM. The zones are intended for the zoned formats that I haven't even bothered with since they are not used on either PC-compatibles or other x86 machines (PC-186, PC-98, FM Towns, etc.). And what exactly do you mean by hardcoded track lengths? Quote: The actual track data is stored in 16 bit words, introducing endianness issues. Why not simply store it as bytes and be done with it? It's FM/MFM-encoded, like it would be on a real floppies, and that's needed to have both data and clock bits so that address marks can be stored correctly. The endianness is fixed, and there's a bit to reverse the endianness which is used for conversion from the FDI stream format which returns the word at reverse endianness. |
Posted at 10:38 on April 5th, 2020 | Quote | Edit | Delete | |
Member Zombie Gumby Posts: 3879 | Quote: I have looked into adding 86F read and write support to the pri utility included in PCE I'm sorry, but would it be possible to simplify and automatize the conversion routine in the future and merge the functionality of PFI and PRI with PSI? I really wish it was as simple as typing: Code: psi track00.0.raw -auto alleycat.td0 Where "-auto" stands for all those things that can be a little tedious to derive and type out manually i. e. datarate, density etc, where the more complex the more liable to various mistakes and confusion on user side. Of course, we should still reserve the option to do it manually in case we run into a special case, but can we do it for 90% of dumps at least? ----- [i]Cheer up! Remember the less you have, the more there is to get.[/i] ----- Edited by Moebius at 10:49 on April 5th, 2020 |
Posted at 10:38 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | Quote: Well, then I must have been looking at an outdated PSI specification. If you could link me to the latest one, it would be nice. http://git.hampa.ch/pce.git/tree/HEAD:/doc Admittedly, the various file format specifications are a bit too concise in places. Quote: RPM slowdown is needed to store formats that don't fit at perfect RPM. The zones are intended for the zoned formats that I haven't even bothered with since they are not used on either PC-compatibles or other x86 machines (PC-186, PC-98, FM Towns, etc.). Right, but the three variables RPM, bit rate and track length are not independent. If you know the bit rate and the track length you can calculate the RPM value. No need to store it. Quote: And what exactly do you mean by hardcoded track lengths? As I understand the 86F specification, storing the exact track length in bits is optional. Can you walk me through how you would determine the length of a given track? Quote: It's FM/MFM-encoded, like it would be on a real floppies, and that's needed to have both data and clock bits so that address marks can be stored correctly. The endianness is fixed, and there's a bit to reverse the endianness which is used for conversion from the FDI stream format which returns the word at reverse endianness. I understand that you want to store an arbitrary bit stream. But why would you store it as a sequence of 16 bit words instead of 8 bit words? Dealing with endianness is unnecessary here. |
Posted at 10:51 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | - hampa: Thanks for the link to the specifications. Will look at them. Quote: Right, but the three variables RPM, bit rate and track length are not independent. If you know the bit rate and the track length you can calculate the RPM value. No need to store it. The 86F doesn't always contain the full track length, that's optional. So for 86F's which do not store complete track lengths, you would have no way of determing the RPM. Also, the ability to have the full track length set only came in 86F v2.12, while the RPM field has been there for ages, that's why. But, I could remove the "no track length" variant, and just store only the track length (in bitcells) and the data rate. However, that would require me to change quite a few things in 86Box as instead of setting a single bit in track flags, I would have to instead specify the track length. But that can be done. And it would even remove the need for a RPM slowdown field as that would again be determined by the track length. At this point, 86F v2.14 might actually become v2.20 due to so many changes but that's for the better. I'll post a new draft v2.20 spec later with all the changes incorporated. Quote: As I understand the 86F specification, storing the exact track length in bits is optional. Can you walk me through how you would determine the length of a given track? From data rate, RPM, and RPM slowdown/speedup + the extra bit cells field if present. Quote: I understand that you want to store an arbitrary bit stream. But why would you store it as a sequence of 16 bit words instead of 8 bit words? Dealing with endianness is unnecessary here. Well, I can do that indeed, but then I'll need to figure out what to do with FDI streams (will probably have to convert their words to bits in a specific way, but that can be done). So, to summarize, I am going to make the track length mandatory and remove the RPM, RPM slowdown/speedup, and extra bit cells stuff, as it then becomes entirely unnecessary, and I going to store the FM/MFM-encoded data in bytes rather than words. So far, so good. Edit: Then I don't even need the zone stuff in, since the RPM for the various sections of such a floppy would be determined by the track length. This is going to simplify things quite a bit. ----- Edited by OBattler at 10:55 on April 5th, 2020 |
Posted at 11:05 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | Draft proposal for 86F v2.20: Code: Specification for 86F format version 2.20: 00000000: Magic 4 bytes ("86BF") 00000004: Minor version (0x14) 00000005: Major version (0x02) 00000006: Disk flags (16-bit) Bit 0 Has surface description data (1 = yes, 0 = no) This data indicates if the corresponding bit on the FM/MFM encoded surface is a normal bit or a special bit (weak bit or hole, depending on the other bit): 0 = The corresponding FM/MFM encoded surface bit is normal 1 = The corresponding FM/MFM encoded surface bit is either a weak bit or a hole: Corresponding FM/MFM encoded bit is 0: Hole (noise on read, not overwritable) Corresponding FM/MFM encoded bit is 1: Weak bit (noise on read, overwritable) Bits 2, 1 Hole (3 = ED + 2000 kbps, 2 = ED, 1 = HD, 0 = DD) Bit 3 Sides (1 = 2 sides, 0 = 1 side) Bit 4 Write protect (1 = yes, 0 = no) Bit 5 Bitcell mode (1 = Extra bitcells count specified after disk flags, 0 = No extra bitcells) The maximum number of extra bitcells is 1024 (which after decoding translates to 64 bytes) Bit 6 Revolutions (0 = one revolution, 1 track has 16-bit number of revolutions) 00000008: Offsets of tracks Note that thick-track (eg. 360k) disks will have (tracks * 2) tracks, with each pair of tracks being identical to each other. Each side of each track is stored as its own track, in order (so, track 0 side 0, track 0 side 1, track 1 side 0, track 1 side 0, etc.). The table of the offsets of tracks is 2048 bytes long, each track offset is an unigned 32-bit integer. An offset of 00000000 indicates the track is not present in the file. As an example, an 86F representing a disk with 80 thin tracks and 2 sides per track, where all the tracks are present in the file, would have the first 160 offsets filled in, same for a disk with 40 thick tracks and 2 sides. Same with only 1 side but only the offsets at 0000000, 0000008, etc. (so every second offset) would be filled in. Track offset + 00000000: Track flags (16-bit) Bits 4, 3 Encoding 00 = FM 01 = MFM 10 = M2FM 11 = GCR Bits 2, 1, 0 Bit rate, if encoding is MFM: 000 = 500 kbps 001 = 300 kbps 010 = 250 kbps 011 = 1000 kbps 101 = 2000 kbps If encoding is FM, the bit rate is half that. The RPM is determined from track length and data rate. Track offset + 00000002: Total bit cells count (32-bit) Track offset + 00000006: Bit cell where index hole is (32-bit) Track offset + 0000000A: FM/MFM/M2FM/GCR-encoded data (track length bytes) Track offset + 0000000A + track length: Surface description data if present (track length bytes) If this is a multi-revolution 86F, then track offset + 00000000 has a 16-bit number of track revolutions, and the track header + data appears for each revolution, while surface description data, if present, can appear any number of times, but only once per encoding + bit rate combination. This needs work to properly make surface data work with flexible multi-revolution support. Track lengths: The total bit cells count is always present. The track is stored as (bit cells >> 8) bytes, with one extra bit cells if the number of bit cells is not divisible by 8. Quite a bit of simplifications to address Hampa's feedback. |
Posted at 11:56 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | Quote: I'm sorry, but would it be possible to simplify and automatize the conversion routine in the future and merge the functionality of PFI and PRI with PSI? I really wish it was as simple as typing: Code: psi track00.0.raw -auto alleycat.td0 Where "-auto" stands for all those things that can be a little tedious to derive and type out manually i. e. datarate, density etc, where the more complex the more liable to various mistakes and confusion on user side. It's the unix way. One job one tool. Converting flux images to either raw bit images or sector images is an inherently complex process that is hard to automate reliably. |
Posted at 12:39 on April 5th, 2020 | Quote | Edit | Delete | |
Member Zombie Gumby Posts: 3879 | Quote: Converting flux images to either raw bit images or sector images is an inherently complex process that is hard to automate reliably. Hm... I thought HxC does it ok? Although it lacks support for TD0, PSI and 86F output it is capable of exporting KF to IMG, IMD, MFM, SCP and other formats just fine. Incidentally, we have been producing MFMs using a patched HxC version (the courtesy of Battler) to later convert them to 86Fs. However, the app crashes on some games and it is apparently something he can't debug. Only the author of HxC can fix it. ----- [i]Cheer up! Remember the less you have, the more there is to get.[/i] ----- Edited by Moebius at 12:43 on April 5th, 2020 |
Posted at 14:27 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | I think we established the HxC crash you were having was caused by my changes. I have looked through the code, and I can't find anything wrong. But well, HxC can wait I guess until we have 86F v2.20 ready, then I can download the latest HxC source code and write an 86F v2.20 module for it, and then we can try to convince the HxC developer to incorporate it. That way we would then have HxC outputting directly to 86F, bypassing the need for intermediate conversions. |
Posted at 15:58 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | I'm looking at the PSI specification now - so if I understand right, every MFM sector has both the SECT and the IBMM headers. Is this correct? |
Posted at 19:04 on April 5th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | Quote: I'm looking at the PSI specification now - so if I understand right, every MFM sector has both the SECT and the IBMM headers. Is this correct? The IBMM header is optional. If it is absent, the sector type is taken from the PSI header and the sector ID is constructed from the physical cylinder, head and sector. In other words, the IBMM header is only required for "weird" sectors. |
Posted at 07:26 on April 6th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | Ahhh, OK. I see now. I'm going to see then if I can find someone with any PSI image that has IBMM headers, just so I know where in the file they are usually positioned. |
Posted at 07:43 on April 6th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | You can easily create such an image yourself, for example like this: Code: psi -n 360 -r 0 0 1 -e c 1 -o test.psi This creates a new 360K image, selects sector 0/0/1 and sets the cylinder ID field to 1 thus requiring the addition of an IBMM header for that sector. |
Posted at 08:47 on April 6th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | Is there any place where I can download a binary of this? |
Posted at 09:09 on April 6th, 2020 | Quote | Edit | Delete | |
Member Pupil Gumby Posts: 14 | The latest snapshots are available here: http://www.hampa.ch/pub/pce/pre/ The *-win32.zip archive contains windows binaries of all emulators and utilities. If you use a different operating system then you need to compile from source. |
Posted at 10:48 on April 6th, 2020 | Quote | Edit | Delete | |
Member Zombie Gumby Posts: 3879 | hampa, A few more questions. Do you plan to add a GUI to PCE some time perhaps? We definitely wouldn't mind a more convenient way to mount images. Also, how reliable is .TC (Transcopy) output in PSI? Last I checked it was "experimental", what would that signify exactly? ----- [i]Cheer up! Remember the less you have, the more there is to get.[/i] ----- Edited by Moebius at 10:50 on April 6th, 2020 |