Added information about the EXT port's pinout (where the Mega Modem
goes), which so far has been undocumented (or underdocumented). The port is
reversed compared to the two controller ports (pins on console, plug on
cable), but it wasn't clear how it affected the pin order.
Thanks to smds to help trace where the pins were connected by looking at
the board.
This year marks the 30th anniversary of Virtual Lab's launch on the
Virtual Boy! I've been working on a Mega Drive remake of it, and
I've decided to put it up for download now:
Controls are more tight, so now you shouldn't struggle with placing the myuu (the pieces you drop).
Graphics are now in proper colors so they won't hurt your eyes.
The fairy effect is different (not a flashing background anymore) so it should be less prone to causing seizures.
Lisa's animations have been expanded and improved. There's also a "Lisa Test" where you can check out all of them!
There's a short tutorial to teach you how to play!
The game isn't finished though, largely due to one game breaking bug
that I haven't been able to fix yet despite spending months on it:
The code to detect the loops is buggy. It mostly works, but there's clearly a memory leak somewhere because it sometimes fails to detect a loop or detects one where there isn't.
Difficulty adjustment isn't implemented. The grid isn't even filled in, so in many cases you can clear a level by dropping a single myuu.
There's a versus mode but it's incomplete, in part due to the above (the bug causes more severe memory corruption than in single player and can render it unplayable). The idea was to let you attack the other player by clearing your own myuu, but so far none of the versus mechanics were implemented.
If I ever figure out how to fix the bug, I may actually bother to finish
the missing stuff.
Tutorial
What is implemented is a short tutorial telling you how to play.
It only goes over the bare minimum you need to know, but it should clear up
the most important things to actually get anywhere (they apply to the
original game too!).
The game becomes a lot easier when you realize that you can use the walls
as part of the loops. It actually kind of becomes required to actually
survive.
There have been a lot of theories about why you can't play as Knuckles
in Sonic 1 while locked onto Sonic & Knuckles (like you can do with
Sonic 2), including a lot of weird ones like the colors didn't work or
that it crashed when gliding into conveyor belts or whatever. Obviously
none of those are the real reason.
The actual reason
The most likely reason has to do with the way Sonic 1 and 2 are built:
Sonic 1 is a monolithic blob where everything is placed tight with no gaps between them.
Sonic 2 is split into coarse blocks (e.g. code, graphics, etc.) which are allocated certain address spaces, leaving some gaps in the unused space between them.
The problem is that both Sonic 1 and 2 had two revisions on cartridge:
With Sonic 1, this meant that the addresses of just about everything changed in each revision.
But for Sonic 2 it was largely the initial code block that was affected (and most thing remained in the same place).
The way Knuckles in Sonic 2 works is that the entire code is replaced with
a rebuilt one in a separate 256KB ROM, while reusing the rest of the data
from the Sonic 2 cartridge (aside from object layouts which are in the main
Sonic & Knuckles ROM).
But with Sonic 1 this would require checking which address to use for each
revision, wasting a lot of extra code and time and also being extremely
error prone. In other words, it just wasn't practical (besides, Sonic
1 would need its own extra patch which would have increased the
cost of the cartridge even more).
Busting myths
Since we're at it:
The colors are not a problem. In fact, Knuckles in Sonic 2 takes the original Sonic & Knuckles sprites and passes them through a table to rearrange the colors to the ones Sonic 2 uses, so they could have easily used the same approach for Sonic 1!
Knuckles doesn't crash when gliding into a conveyor belt in Sonic 2 (not even the Wing Fortress one if you fix it), so I doubt that would have ever been an issue in Sonic 1 either.
mdtiler can generate sprite mappings (manually) using the
sprite instruction, which both reads tiles and generates a
sprite mapping entry in one go. The format used by mdtiler
looks like this:
2 bytes: X coordinate
2 bytes: Y coordinate
2 bytes: Tile ID and flags
2 bytes: Sprite size
And the list is ended with $8000.
But in hindsight, it's kinda wasteful: the upper 12 bits of the sprite
size are never used (always 0). Even if you want to cram in flags in the
unused space of the sprite table, the upper 8 bits are never used at
all. Also, to check the end of the list, you need to check if X =
$8000, which wastes cycles.
Probably a better idea would have been to do this:
2 bytes: Sprite size
2 bytes: X coordinate
2 bytes: Y coordinate
2 bytes: Tile ID and flags
And again the list ends with $8000 (or larger). Then the
"end of list" condition comes for free when reading the sprite
size since the sign flag will be set, avoiding wasting cycles on a
cmp instruction.
Maybe one day I'll update mdtiler to support the new
format, or even custom formats (where you specify the order of each entry).
OK so on February 10th some asshole thief cut off some cables from a pole
in order to knock down a camera and in the process left us with no landline
or internet.
Now, the telco in question used to be Telefónica (now Movistar) and they
already had a reputation of taking their sweet time and leaving their
customers two weeks without service upon any minor hiccup but wow, the new
owners are much worse.
So we fill a complaint. No news, later we noticed that they marked the
issue "fixed" without doing anything at all. We fill another
complaint and they mark it fixed again within two days without doing
anything. What the fuck? Whenever we'd get them to talk (nearly
always at night, once they replied at midnight) they'd insist
that there's an active report (yeah because we just reopened it
you dumbass) and to keep waiting (one of them said to wait "12
work days" what the heck?) and would put different excuses each time
(they even claimed the address was wrong) all this while
consistently closing reports as "fixed" after 48hs
(automated?). They did this shit six times in a row.
We found the address of their offices in Argentina and decided to directly
pay a visit to force their hand… there was nobody in the lobby. The
building was freaking empty. What the fuck, does anybody even
work there?
Then finally after over a fucking month these assholes finally
admit that the reason is that we're on broadband (because they refuse
to do fiber in this zone) and that they don't have the required
equipment anymore and that as such they wouldn't offer us internet
service anymore ("but we're always improving" shut the fuck
up) and that at most they'd offer us some device to make landline
work. Oh, and they knew this since the first time they closed the report
while marking it "fixed" instead of "won't fix"
because they wouldn't tell us that they weren't going to bother
at all. All this while demanding us to pay the monthly bill for the month
where they kept actively refusing to provide service, by the way.
FUCK. OFF.
So there goes one month.
We finally convinced the landlady to switch to another company,
and this still took over another month worth of waiting because,
on top of the usual ISP shit that makes you waste time, apparently this
crap went on through the whole area and the competing ISPs are short on
staff to deal with the sudden surge in demand for them, because I guess
that Movistar is happy to drop an entire neighbourhood.
Oh, and stop sending demands to pay the overdue bills when
you already admitted you won't restore service and we already fucking
cut you off, but I guess that you're a chronic bully who
needs to punch every single idiot around for their lunch money, amirite?
Because Movistar sent us a warning a few days ago over March where we
didn't have any service at all. Yeah sure, GET THE FUCK OFF.
NOW.