[ via TOR :: whatsnew :: ax.25 :: archive :: hupmeme/24h/7d :: hardware :: pinouts :: inventory :: download :: rss ]
[ job wanted ]

:: 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.

And here it is. Yes I forgot to put on the USB plug sheath as always.

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:

Yep, it's shit.

Obvious errors

And with another fastloader:

It's another kind of shit.

Borrowed Time's opening animation didn't play to its end.

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:

The Plussy is just plain friendlier to use with split graphic/text mode, and windowing ESC keycommands. As Pigmy said once, he likes C=64 for the games, and Plus/4 for work.

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 du's output).

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...

[ e-mail ]
sidripalliance kq5
apple india uboot bombagyar