:: 2018-03-12 18:57:08
The 1541emu cable (type 1 version)
There's a plethora of cables which connect a CBM device to other computers. For one, I'm a happy user of an XE1541 cable which is (with the fine addition of 64HDD.EXE) perfect for making D64 images available for a stray C=64 or Plus/4. Or even better: creating a huge T64 with single-file games or utils which can then be loaded without painfully managing multiple D64 files.
Now, the obvious drawback of these methods is the complete lack of fastloader support. That can't be done it with an XE1541 cable - although I've tested a yet unreleased emulator for Linux which tried to do just this, but with no results. What the lack of fastloaders means: no demos for you (at all), and very few games. And those that run... well they "run" at the abysmal "speed" that Commodore hacked together with the 1540. There's pretty much one single product which can emulate a real drive for a real computer: and that's the 1541 Ultimate of course, but that's only for C=64 users as only the Ultimate-I (unavailable since ages) was standalone, the Ultimate-II can only be managed from a C=64 or 128. You'll need to power up both your C= machines just to play some game on the Plussy.
However there's a little-known thingy called 1541EMU, which is pretty much an 1541 emulator for DOS. Go on read about it, I'll wait.
First a special cable has to be constructed. I've successfully persuaded Werdy to create one for me, and it pretty much worked for a while (then it didn't). In any case, we've borrowed a cable from STA (of Star Commander), and reworked it to include an USB power plug in addition to the game port connector.
It works admirably with normal (non-fastloader) D64 programs, but who wants that? Let's try and emulate a fastloader! ... Well that didn't end well now did it. Turns out the transfer is incredibly sensitive (as advertised on the site), so your mileage WILL vary. But what does it depend on? Pretty much everything: the parallel port chipset, the computer, the cable length are the main culprits. Also, 1541EMU segfaults with some C=64 fastloaders due to some bug(s) in the code.
The good news? Well it works much better with most Plus/4 fastloaders! Hungarian coders rule, I guess. :) Interestingly it also works flawlessly with whatever - incredibly fast by the way - fastloader the Retro Replay (C=64) has. But a fast initial loading is exactly zero help with games and demos, all with their own fastloaders.
So let's test it. The next thing to do was to create a graphical pattern for testing purposes. A lot of $01 values ranging from $2000 will suffice: there would result in several vertical lines.
Then try to load it with a fastloader:
And with another fastloader:
Luckily there's an I/O tuning variable in 1541EMU, and sure enough (after some trial and error) cranking it up to +250 (highly dependant on the parallel port, PC, fastloader), the test pattern loaded cleanly:
All in all, this is obviously not a perfect solution either. It is quite workable though, if you devote quite a bit of time to debug its issues AND also use a Plus/4, not a C=64. I've successfully played Laser Squad, Borrowed Time, Test Drive 2 (this one on C=64) and some other stuff, so it's obviously at least of some use for real-iron hobbyists. For serious work you probably already have an 1541 Ultimate or a real 15x1. Of course a real drive comes with the additional fun of all kinds of smokes and sparks, also with neverending hunt for replacement parts which some may find enjoyable, I sure as hell do not. Once I've even seen a switched off 1571 emit smoke, because some bright minds built some limited lifespan capacitors right into the power socket too. For science, I guess.
This was all with a type-1 cable. The type-0 cable should be more "electrically compatible", so I'd be more than happy to try it out. I'm not very adequate with a soldering iron, so donations are welcome as always. There's also the fact that 1541EMU is not being worked on anymore, and Ville Muikkula just points everyone at the Ultimate-II which is understandable. The source is available though, so at least the segfault issues could be fixed. By someone. Someday.
UPDATE: Ville suggested that automatic end-of-interrupt feature of the PC interrupt controller could be used in 1541EMU: https://scalibq.wordpress.com/2015/12/15/pc-compatibility-its-all-relative/
:: 2018-03-11 17:27:11
ZFS vs Hammer vs Hammer 2 test
Yep 'cause why not. Well actually I wanted to see if either of the Hammers can do a better job than ZFS at storing Windows 2008 iSCSI images with only "a few" differences between each other. Because, you know, ZFS deduplication is a bit icky. For one, it doesn't work if all the files are in the same directory, who knows why (EDIT: okay that's bullshit, I got distracted by
At first I wanted to do it all via iSCSI, but it didn't work on DragonflyBSD at all (despite no problems at all on OS X, Windows or FreeBSD):
1040:1 iscontrol NAMI "/dev/iscsi0" 1040:1 iscontrol RET open 5 1040:1 iscontrol CALL umtx_wakeup(0x800453800,0) 1040:1 iscontrol RET umtx_wakeup 0 1040:1 iscontrol CALL umtx_wakeup(0x800453800,0) 1040:1 iscontrol RET umtx_wakeup 0 1040:1 iscontrol CALL close(0x4) 1040:1 iscontrol RET close 0 1040:1 iscontrol CALL ioctl(0x5,0x80d86905 ,0x7fffffdfd650) 1040:1 iscontrol RET ioctl -1 errno -3 Unknown error: -3
Don't you just love when these "errors" happen? I know I do. In the end I had to make do with a local, physical HDD. Created Hammer 1, copied the first Windows image, checked the free space then ran deduplication:
test 77602816 31723760 45879056 41% /mnt # time hammer dedup /mnt Dedup running Dedup /mnt succeeded Dedup ratio = 3.36 (in this run) 30 GB referenced 9145 MB allocated 24 MB skipped 1 CRC collisions 0 SHA collisions 10 big-block underflows 345191 new dedup records 22622437376 new dedup bytes 0.578u 99.718s 12:30.55 13.3% 83+199k 699074+0io 14pf+0w
This is the result:
test 77602816 10017008 67585808 13% /mnt
10GB is just about the size of the used space (9G) on the Windows disk, so there's no extra win here. Au contraire, it takes up 10% more space than it reasonably should! Let's acquire the second image:
test 77602816 41562016 36040800 54% /mnt Dedup ratio = 5.91 (in this run) 90 GB referenced 15 GB allocated 38 MB skipped 4 CRC collisions 0 SHA collisions 207 big-block underflows 699047 new dedup records 45812350976 new dedup bytes 1.359u 169.793s 40:59.66 6.9% 81+194k 884242+0io 26pf+0w test 77602816 19331312 58271504 25% /mnt
Well it looks like nothing was deduped at all except for all the empty (0x00) 20GB spaces in both images. That's a disappointment. Now keep in mind that Hammer can perfectly deduplicate two images if they are exactly the same, so obviously my differing Windows 2008 images bear enough dissimilarities that Hammer can't dedupe anything from them. I'll need to work on that somehow. They are completely defragmented of course. I'll probably need to use a more sophisticated defrag solution which would rearrange all the files into more-or-less the same order on both images. Oridunno.
The Hammer manpage left me quite flabbergasted since it says "HAMMER snapshots don't preserve source mtimes and atimes." What the fuck. Whoever thought that would be a good idea? Anyways, bravely onwards to Hammer 2! Now this beast finally supports compression (LZ4 at that) so it'd be a reasonable expectation to see it catch up to ZFS in terms of image storage. Let's see what happens with 1 image:
/dev/ad6@DATA 77508608 8063424 69445184 10% /mnt
And after two "dissimilar" ones:
/dev/ad6@DATA 77508608 15274240 62234368 20% /mnt
Hammer 2 doesn't have a separate deduplication command to my knowledge, so I'll assume it's already ran online. The same for ZFS+LZ4 (no deduplication!):
test 74.5G 5.29G 69.2G 7% 1.00x ONLINE - test 74.5G 10.3G 64.2G 13% 1.00x ONLINE -
So yeah, Hammer 2 (with LZ4) is a bit better than Hammer 1 (i.e.: nothing at all), but ZFS takes the prize. As if anything else could have happened.
:: 2018-03-08 08:48:47
More FreeBSD 11 glory
# kldload snd_maestro3 -> page fault
Yep, entirely fixed by the user downgrading to 8.4. The additional bonus being him being able to use the "nv" driver instead of vesa...