So, Activision's Board held what appears to be a perfunctory -- but clearly wholly in-house -- investigation into itself, and Good News, Everyone! Nothing wrong! Because Activision said so. Check it:

Kotaku - Activision Blizzard Clears Itself Of Any Wrongdoing
Reuters - Activision board says no evidence senior execs ignored harassment cases
Techspot - Activision investigates itself and unsurprisingly finds no evidence of systemic harassment
Eurogamer - Activision investigation claims "no widespread harassment" at Activision
Ars Technica - Activision’s internal investigation finds no “systemic issue” with harassment
The Verge - Activision Blizzard investigated Activision Blizzard and found Activision Blizzard didn’t do anything wrong

And that's just from the first page of DDG search results (2022-06-20). So that's Activision Blizzard and their fuckstick subsidiaries (and, by extension, their new foster parents, Microsoft) vindicated...

Never Again

I bought Crash 4, on sale, even well after I knew Bobby and his crew of frat boys were at it. I felt guilty as hell, and Unreal Engine 4 (which I can't blame Activision for -- I'll have to reminisce about Epic Megagames to place that blame) gave my NON-PRO PS4 a great workout and it served as a fan stress test.

I wish anyone else (except perhaps Epic Games or Ubisoft) published Toys for Bob's work. Crash 4, despite clearly being non-optimized, is a pretty good game.

My history with an entity called "Activision" goes back to the early 1980s. The games were great and fun to play. Eventually I'd be able to buy some of these games with my own money instead of hoping Dad would buy it.

The Activision David Crane and crew made after they left Warner Communication's version of Atari stopped existing the instant Bobby took over. It went from "Good games" to a big hole where I barely knew what games were out, to waking up and realizing Activision was "that company that made that dopey shooter game EA competes with."

Note that I don't care about the video game company making money. That's OK; Bobby and the executive component of a video game company don't care about their output being fun, or even playable, so we're even.

I think I've bought about 3 games, including Crash 4, that have had Activision's involvement. There won't be another.

Never Needed To

Blizzard, on the other hand, was a great unknown for me. Most likely for the best.

"Those guys who make that Warcraft game and charge monthly -- for a GAME" didn't get much attention from me chiefly because I found the very idea of a monthly game subscription to be insulting. So not only did I miss their other games (because "who is Blizzard?"), not only did I miss Warcraft and Diablo ("like HELL I'm paying per month!"), I just had no attachment to what was most likely "good Blizzard."

Then Bobby's Bizarro Activision bought Blizzard, and I knew I would never form any attachment.

It's Not Worth It

It's clear to me that the executive components of Activision and Blizzard will not be held accountable for anything. Quite like the military (I could write an entire section on what it was like being enlisted there), there will be fake "punishments" and strongly-worded admonishments from the executive component to the rank and file that "THESE ARE REAL PUNISHMENTS", and nothing else will be done. Nothing will change for the better for the targets of abuse.

The conclusion is the same, whether employee or consumer: The only winning move is to not play.

In closing, while I don't overtly wish death on Bobby, I do hope the last couple years of his life is a painful, losing battle. (You pick the disease; there are plenty to choose from.)

PUNT TO PERMANENT SIGNAL TRUNK.

I think it's high time to put a tiny blurb out in remembrance of (the sadly late) Bob Bishop's APPLE-VISION for the Apple II.

It was written in INTBASIC, of course. But it also took advantage of at least two major parts of the then-optional Programmer's Aid #1 (and unfortunately, only) ROM Apple II users could buy to put in the otherwise-vacant D0 socket. So this had not just high-res graphics and sound, but other tricks, such as TEXT on the hi-res screen (hi-res char generator).

It also showed how hi-res shapes would look (this post's icon is of the guy on TV).

If you use Linux, there will come a time when you update the system, only to have the machine fail to boot. Typically, you're dumped at a screen that looks like the one below:

I happened to have this happen to me, and the first thing I reached for was Super GRUB2. This usually works, but in my case, the boot disk didn't boot my system, so I was stuck with manually getting my system back up.

So I went a few rounds with Google, and eventually stumbled upon this really useful guide that got me reacquainted with all the GRUB stuff that I immediately forget after I fix boot issues. While this guide is pretty awesome in explaining what needs to be done to boot most systems, there were a few extra steps I had to take to make my system boot.

I set this system up with LVM, and the root filesystem is on LVM. In my case, GRUB2 would start normally, and then fail for some reason, just dumping me to a GRUB shell. Initially, GRUB2's environment looked like this:

OK, the prefix is set to a plausible value (since my /boot is in /dev/vda1 in this case), but the LVM isn't present as shown by the ls command. Using ls with nothing else lists the partitions known to GRUB2. You can use ls -l to get more information about the partitions. This is useful if you are not sure where your boot partition or root filesystem is.

The next step, since I know my root is on LVM, is to make GRUB2 recognize LVM. We do this with the insmod command. However, before this, you might not know the name of the module to insert. You can do an ls /grub to find the module name. (You may want to have pager=1 set before doing this, as there are a lot of modules.) In my case, I want lvm.mod. So we will insmod /grub/lvm.mod and hopefully have visibility to the currently-invisible filesystems on LVM.

We want the latest kernel, and since we have LVM, we know that the root device will be under /dev/mapper. We also want the root filesystem to initially be mounted read-only. So now we can assemble our linux line. In this case, it pans out to the following:

linux /vmlinuz-3.2.0-49-generic root=/dev/mapper/puchuu-root ro

You will usually need to load an initrd as well, so we can get that out of the way by loading the initrd from the same version as the kernel we loaded: initrd /initrd.img-3.2.0-49-generic

At this point, everything is done loading, and we can boot with the boot command. With any luck, the system should now boot normally.

Once you're done recovering, you can now (hopefully) fix the GRUB error that caused the system to fail in the first place. Since I'm using Ubuntu, this is done with update-grub.

And that's it. You can try rebooting and see if the system starts properly.

--
In this case, I intentionally moved grub.cfg so GRUB2 would fail, just to demonstrate to you (and again to myself) how to manually boot the system.

NOTE: It took years for me to get (or emulate) hardware other than a disk][ Apple ][e, so it took years for me to realize that the following code works ONLY on ][ series that have a real disk][ controller (or equivalent). The //c and IIgs seem to have code that's much different in the $C600 slotspace.

Oh well, this ups the ante for me to make a version that works with ANY Apple or compatible!

Not that anyone else would care, but I've rewritten the evil "getting my Merlin-fu back" code so it makes more sense. I've also corrected some symbols, as I've disassembled and documented the ProDOS boot block since this stupid trick.

Furthermore, I apologize for the use of <pre>, but using nonbreaking spaces would suck more.

eslingc 20040803

********************************
*DISK][ STUPID TRICKS          *
*ESLINGC 20040803              *
*Merlin8 v2.57                 *
********************************
	 EXP	OFF
	 TR
	 TYP	$FF	;TSYS
*-------------------------------
BOOT	 = $801		;location of boot sector
PPATCH	 = $87A		;ProDOS patch addr
DPATCH	 = $84A		;DOS patch addr
BLKRDFE	 = $912		;ProDOS block reader frontend
UNIT	 = $43		;Unit (%DSSS0000) for ProDOS
RWTSLOAD = $8FE		;page byte of RWTS loader
DRV2PROM = $8636	;modify fake PROM drive byte (depends on controller!)
PROMBASE = $8600	;base for the PROM
C6PROM	 = $C600	;most everyone has slot 6
REALSLT  = $C006	;enable real slots
A1L	 = $3C		;from address for move
A2L	 = $3E		;length for MOVE
A4L	 = $42		;to address for MOVE
MOVE	 = $FE2C	;Monitor MOVE subr
*-------------------------------
* LDAD macro to reduce tedium for fixing adrs bytes
*-------------------------------
LDAD	 MAC		;load 16bit number in 2 locns
	 LDA	#<]1	;lob
	 STA	]2	;little-endian
	 LDA	#>]1	;hob
	 STA	]2+1
	 <<<		;not >>>
*-------------------------------
	 ORG	$2000	;TSYS requirement
*===============================
* relo program and setup
*===============================
	 STA	REALSLT		;ensure we're on real slots
	 LDAD	C6PROM;A1L	;from slot ROM
	 LDAD	PROMBASE;A4L	;to RAM "PROM"
	 LDAD	C6PROM+255;A2L	;len=$100
	 LDY	#0
	 JSR	MOVE		;go move it
	 LDAD	STUB;A1L	;move the stub
	 LDAD	PROMBASE+$F8;A4L ;to PROM base
	 LDAD	SEND-1;A2L	;amount of code to move
	 LDY	#0
	 JSR	MOVE	;getem
	 INC	DRV2PROM	;make PROM boot from drive 2
	 JMP	PROMBASE	;boot from drive2
*===============================
* end of relo program
* the new end of the disk][ PROM follows
*===============================
STUB				;let edasm do the relo work
	 ORG	PROMBASE+$F8	;the stub assembles at $86f8, this is also controller-dependent
	 PHA			;save A register in case of ProDOS
	 LDA	BOOT
	 CMP	#$38		;ProDOS/SOS?
	 BEQ	:PRODOS		;yes
	 LDA	#$4C		;else, assume DOS and pray
	 STA	DPATCH
	 LDAD	DOS33ENT;DPATCH+1	;jump to DOS 3.3 stub
	 PLA			;restore A register
	 JMP	BOOT		;proceed to "boot"
:PRODOS	 LDAD	PENT;PPATCH	;program loader to JSR to our stub
	 PLA			;restore A reg
	 JMP	BOOT		;(re)enter into $0801 loader
PENT	 PHP			;save proc status jic
	 LDA	UNIT		;get slot/drive
	 ORA	#%10000000	;turn on drive 2
	 STA	UNIT		;make it so
	 PLP			;get original proc status
	 JMP	BLKRDFE		;carry on to block reader
DOS33ENT LDA	RWTSLOAD	;get RWTS loader page
	 STA	:DOSP+2		;self-modify to get relocating DOSes
	 LDA	#2		;drive 2
:DOSP	 STA	$C607		;into $x707 (make sure this is a 3byte)
	 JMP	(RWTSLOAD-1)	;jump to RWTS loader
	 ORG			;apparently will return to $20xx this way
SEND				;EOF(relo code)

NOTE: The following works only with a real disk][ controller. See the source for more details.

Have you ever owned an Apple ][ series computer? Ever do stupid, yet highly amusing stuff with it? I have, just to (re)learn my machine.

I. Booting from drive 2

Ok, I admit I hadn't had much sleep the previous night, but when I woke up, I thought, "Hrrrmm... what if I could boot from drive 2?" So the disassembling of PROMs and stuff began. Herein is a howto.

Altering the boot PROM

In order to boot drive 2, you must somehow activate drive 2. The following snippet is from the Cx00 PROM for the disk][ controller:

The X register has the slot number*16 in it on entry to these instructions. The byte at $C636 needs to be changed to 8B in order to make drive 2 active, however. So, we move the entire $C6 page to another $x600 location. The location MUST be at $xs00, tho, where x will be "4" in my example, and s is the slot number ("6" in most apples), hence, we will "move" the PROM to $4600 with this command:

There. We now have a writable "PROM." Let's make drive 2 be active:

The "PROM" in RAM will now boot off of drive 2... for the FIRST sector.

The reason our fake PROM needs to be at $xs00 is because of this code:

Woz pulled nifty "latent stack byte" tricks to get our slot number. Mmmmmm, hackery.

Making DOS use drive 2

If we were to try booting our fake PROM at this point, we'd succeed in loading track 0, sector 0 off of drive 2. We'd also get any sectors the boot sector loads until the loading routine for DOS 3.3 assumes we're on drive 1! for DOS 3.3, we get 9 sectors loaded at $B700 (this is all of RWTS, I believe) so that it can load the rest of DOS using the "read group of pages" routine found at $B793.

Our area of interest starts at $B700, where the $801 loader jumps, oddly enough:

We need to change the byte at $B707 to $02 to make DOS use drive 2.

Making PROM stubs

Normally, this wouldn't be so involved. However, there exist diskettes on which there resides a relocatable DOS that loads in at $1600-$3FFF, getting relocated up to $9600 for your 64k apple. This makes for an interesting situation. Booting relocatable DOS without providing for it will result in an unspectacular crash. Therefore, we must find out where the DOS loaded up. This is rather easy, as the byte at $08FE contains the page location of our RWTS loader at $B700 for a 64k fixed DOS. This is constant, no matter what DOS 3.3 you're booting, so we can use that byte to modify our "PROM" stub detailed below.

Making the PROM modify things

The following original instructions must be modified:

The code at $084A is simple. Our PROM will modify this line to be:

The stub code that replaces the instruction at $46F8 and would otherwise run into the next slot is this:

The stub above will modify the $0801 loader to jump back within the stub, then execute the $0801 loader. After loading RWTS, the stub will self-modify where to place the drive byte depending on the page byte of the loaded RWTS in $08FE. Once that info is filled in, the indirect jump to the RWTS loader fakes any normal DOS 3.3 into booting completeely and correctly from drive 2.

Assuming you booted DOS from drive 1 and typed this all in, you can save your work:

This code can be BRUN safely because it never RTS's to anything.

Booting from drive 2 using ProDOS

As the source shows, booting from drive 2 using ProDOS is possible, but a tad trickier. For ProDOS, the boot block is actually 2 sectors long. We need a convenient place to jump to our stub and modify the UNIT byte at $43 before anything happens. There's a JSR at $0879 that will let us do our magic. We modify this to jump to our "stub":

For ProDOS, indicating drive 2 is easier than for DOS 3.3 in that no code in the PRODOS image needs to be hacked. All we need to do is flip the high bit of the ProDOS temporary Unit number (stored at $43) on to indicate drive 2, and the boot loader and PRODOS take care of the rest:

This, combined with the common task of making a fake "PROM" and hacking it, enables ProDOS to boot from drive 2.

The Source

The source takes care of booting either DOS 3.3 or ProDOS from a single binary. It's designed to assemble in the ProDOS version of Merlin, though you could conceivably assemble it in DOS 3.3 if you hack the TYP op out. Porting it to other assemblers could be tricky (it's not too hard to port to EDASM, though the "relocation" trick I (ab)use in Merlin may gum the works.).

Happy Hacking.

When I first saw a computer, it was an Apple][(+?) ... Also, the first computer I'd ever programmed for was an Apple][(+/e). Those reasons alone aren't why I stuck with it, however. Set your watch to October of 1986.

I'd been in my first computer class in HS which I was truly interested in. This evening, we went to the public library to get an orientation on their computers, which happened to be a ][e and a ][+. To prove that I was green about computers in general, I'd brought my TRSDOS-formatted floppies in and asked the caretaker to try booting one. Naturally, it failed.

I took the simple test and got my orange dot on my library card anyway. This was the beginning of loads of tube time on these two machines.

I started out by running a few of the BASIC programs off the System Master, then LISTing them to see how they worked. I had no clue (back then) how a "CALL 2080" made the Apple do all that nifty shit (in this case, it did a CATALOG, then let you select what actions to perform on the file). I had no clue about anything Apple. What I DID have, however, was access to loads of documentation on these machines!

Thanks to having the docs, I taught myself FPBASIC, a bit of INTBASIC, and most importantly, 6502 assembly language. I'd also gotten proficient in doing things with the disk -- sector editing, CopyII+ parm file hacks, hacking DOS with nothing more than a well-worn copy of _Beneath Apple DOS_, getting into ProDOS, etc... There wasn't as much documentation as I needed, but I got good results with what I had and what I reverse-engineered on my own, so that made me stick with it.

Contrast this to the TRS-80 Model III I'd been working on that first year. Sure, I had a GWBASIC-like reference available, and used it... but by the end of the year, I'd had a taste of assembly language, and there was no TRS-80 memory map, no Z80 instruction set (hell, I didn't even KNOW what CPU was used in the TRS-80 back then), no docs of which locations were special for TRSDOS or the TRS-80 in general... none of that! All of this was available to me for the Apple, or I could find out if I really needed it.

Many years later -- and despite the fact that I'd thrown most of my best docs in the rubbish bin right after I'd drank an excess of Stupid -- I can still find out what I need to know about the Apples I have. Yes, I still use the Apple today.

I'm currently working on some ROM enhancements to the Apple][e... it's going pretty good, but I find that enhancing one piece breake another...

Did I mention that, even though I'd been using an Apple in some way since 1984, I still learn new things about it today?

Simple: I have grown rather tired of the color scheme over the years, and it's become ancient. To the best of my knowledge, users still have the ability to make a web page appear in whatever colors they want. That job gets hard if I try to fight with them, so I've removed all the color-altering junk from the stylesheet.

Not-so-simple answer: I usually detest white backgrounds. That was the whole impetus for my having a scheme that was significantly darker. But I ended up falling into a rabbit hole which was connected to some labyrinth, where now I'd have to literally fight with everything (and possibly, everyone) to get a color scheme that looked decent. I've had it with this game after so many years.

I'm no web designer. I'm not required to make things "pop." I'm not famous, or significant, or remotely unique. Usually, I just want to convey a small amount of information.

Therefore, I believe I should leave the color scheme of this part of the web at its default, and put the choice (if it still exists) back in the user's hands.

... and it enables me to be lazier than I have been.

In an act of simplification, I've decommissioned the old content manager that drove the mumble, and with that, the old posts in the Apple II section disappeared. They will appear here momentarily.

CSS is incredibly complicated. If I was an unscrupulous bastard, I'd just use <table> formatting and pretend it's 1995. (It can be inferred from the mere look of this page that its author is stuck in 1995, but that's a different post.) Why is this?

Well, I'll tell you why. Just look at the page source for anything generated by my weblog software of choice, and you can see some of my frustration. Whereas I could just wrap the whole steaming pile of turd in a table and call it a day before, with CSS, I not only can't do that, but I have special, evil, unclear rules I must figure out and abide by.

First is the concept of CSS in conjunction with HTML, namely <div>. Imagine this block-level element with CSS as the CSS equivalent of <p> (which itself is another block-level element). Depending on which CSS tutorial you use, they tell you that these things stack underneath each other, take up 100% of the width of the page, and insert line breaks between each other.

How I wish that were true all the time.

In reality, if you use float: to float a div anywhere, they stack up right next to each other. REMEMBER this. If you want floating divs and also want them to "press return," you MUST use width:100%; or else you'll be swearing like John McEnroe at Stockholm in 1984.

Also remember the difference between a block-level element and an element that is inline. The icon on this post? I had to make it inline because otherwise I would have no way to make the divs line up properly. (What, was I going to guess how wide my text was beside the icon?) So I made it inline, and the worst that happens is the text flows around my icon. Fine with me.

Christ... and that's just basic block-level elements! It took me another chunk of forever to get the heading to properly display without this stupid gap between the lines. My only crime was that I was using a different weight and size of font.

This is why lazy people use images, and <table>, and javascript, and all sorts of other crap as hacks. (Disclosure: the date in the footer is the result of a javascript program.)

In conclusion, to all you out there who think web developers don't do real development, I challenge you to write a web page using modern web technologies (the current HTML and CSS will be fine) and have it work properly in the 5 major web browsers. Extra credit if you keep your sanity and hair.

More filler and testing stuff. Wonder how this will present itself.