foone

It was deleted because it was posted here.

yeah, same. they really need to be blocked from HN, permanently.

my favorite part of this bullshittery that there's quotes around my name. it's just my name. it's on my license and everything.

anyway you can keep linking to my threads. I just won't like it.

ADHD. If I have a long-form blog post to write end, I get caught up in going back and rephrasing and re-editing and such, and it never gets finished.

Twitter's paragraph-size chunks with minimal editing (if I really have to, I can delete the last post and re-create it) means that I can't get stuck in the process of editing and revising, so I have to keep moving forward.

So it's really the only way I can write. My wife's gone through and rewritten some twitter threads into a blogpost for me, but she hasn't gotten to this one yet.

BTW, You can also use a threadreader/unroller to make a pseudo-blog-post out of it.

Feel free to write it as one!

But personally I can only do it this way, as I've got rather bad ADHD. So when I'm writing, it's a choice between "a rambly twitter thread" or "an unfinished never-posted blog post".

Yeah, if you read to the bottom I apologize for this.

I made this rant at 5am after being in the hospital for 8 hours, I could barely see the screen. It's amazing the thread doesn't have even more typos

A few people have mentioned that! I'm keeping my eye out for a second one, so if I find one (or I figure out a way to talk to off-the-shelf hardware with this one) I'll send it his way and we can exchange disks.

The drive itself was actually very powerful and capable, it just was very limited by having to talk to the C64 using the Vic20-compatible interface, which had issues.

That's why there were so many products for the c64 to fix it: Epyx Fast Load cartridges, for example. And plenty of games worked by having you first load a very simple file that just installed faster disk IO code and then used that code to load the rest of the game.

That's basically what Disk II drives did on the Apple II, just for EVERY (bootable) DISK instead of only some of them: The first bootloader is encoded in a simplified method so that they can save firmware space, but the first bootloader is just better disk IO routines to load the rest of the disk.

Very neat! That sounds like it's pretty similar to this one then. I wonder if the FISK was directly inspired by the DiskFax? I'm hoping to get in touch with the designer so I may have some answers soon.

I'd love to see those schematics if you can find them!

oh, hello!

I've been looking for a DiskFax machine for a long while, in fact I think it was my searches for that that ended up finding this one (on ebay).

That was a few years before the FISK, right? (FISK was ~1993). What was it internally? Something like a 6502/Z80 ?

Sorry. I've got ADHD, so that's really the only way I can usually do these things.

I'm planning to videoify it in the future, if that's more your style.

I checked, and that means it's basically illegal to fly a drone in the bay area: https://pbs.twimg.com/media/DB54FczUQAEQ5D6.jpg:large

I've actually got the game in-box, that's how I remembered it. The only web-version I know of is the one based on the novelization, which is only available on internet archive now: https://web.archive.org/web/20020424235218/http://portal.sto...

I just now realized this story I'd been ignoring isn't about the game "Portal" for the Apple II. Activision published a game with that title in '86 about exploring the future internet after the death of all mankind.

We also had weird CCITT Group 4 issues, because of someone trying to be extra smart and convert TIFF to PDF without a recompress (PDF supports Group 4 compression too, so you can turn a Group4 TIFF into a Group4 PDF by just swapping the header!)

I didn't mean it was definitely the same company, just a similarly annoying TIFF issue.

I bet I worked with the same company when I was with the government. We had a subcontractor who'd been hired to digitize something like 200 million paper records (they made it about 50 million in before we ran out of funding). But a small fraction of the TIFF files they generated wouldn't work with any of the tools we had on hand.

It turned out that Windows 98 shipped with an Imaging program (Licensed by MS, not written by them) which predated the standardization of the JPEG-in-TIFF subformat, but they'd basically guessed at how it would work and shipped that. The final spec (and the version of JPEG-in-TIFF nearly everyone else implemented) ended up being different. So basically nothing could read it.

We ended up calling them up every time a customer found one of these files and having them print out that image on one of their windows 98 machines, and scan the printout back in using one of the newer machines. Sure, we lost some quality, but at least the customers could access the data now.

For a time reference, these broken images were still showing up in newly scanned documents in 2011 (when we stopped working with them due to massive fraud), so they must have been using their Win98 scanner systems even then.

I think they mean use the magic numbers so you can limit to common file formats like jpeg/png/gif/bmp/tiff/etc instead of just dumping everything to imagemagick, which has the side effect of allowing "weirder" things like MVG/MSL which are imagemagick-specific macro languages which let you do things like wget a remote URL.

I swear I've had amazon ask me if it was alright to deliver to a new address on weekends. Maybe that's a recent feature?

That was a joke. Sorry, more than one person thought it was serious.

It's an old trick for compression/size limit competitions. You have N bytes allowed, but you can get an extra M bytes by putting them in the filename (minus however many bytes it takes to access the filename)

like if you several uncompressable (random) files you can "compress" them further by moving some of their bytes into the filenames.

Seems unlikely. This page is at least 16 years old.

Ollydbg run traces and in a plain text format. I'm constrained by my target application only working on older versions of windows, so I can't easily insert a compression step in the log generation or switch to a more compact binary representation.

(I'm currently looking into solutions like a custom filesystem driver, running a second VM and using internal networking to stream to a FUSE filesystem, or possibly even hooking the filesystem access of my debugger and inserting a compression step into WriteFile() calls)

Yeah, one of my main debugging tasks right now is primarily limited by my SSD write speed. Instruction-level traces take 9gb at minimum, any more significant work takes quite a lot more.

There are some. I had to deal with a microsoft project using one, and in the end the only solution we came up for dealing with it was extracting the decompression code out of the EXE file and embedding it in a DLL (at run-time, to prevent copyright infringement issues).

BTW, the random module has a "choice" function, which takes a sequence and returns a randomly chosen element from it. So instead of "result[randrange(len(result))]" you could have "choice(result)"