TapamN

I got one of these for my birthday in 2003, and I'm still using it. The Data Link USB "only" has a battery life of about a year. The 3-year life Data Link would be the older model, that optically received data from a PC by watching light pulses from a CRT.

I don't know why he's complaining about the Windows 98/XP PIM software. It worked fine, and it's open source <https://sourceforge.net/p/datalinkusb/code/HEAD/tree/USBPIM/>. It does not work on Windows 10 and later, however. I looked into it years ago, and it seemed related to the GUI code (I think it used MFC?) and not anything involving watch access. Probably fairly easy for someone familiar with Windows dev to fix, especially with the source. Edit: Wait, I misread. He was complaining about the SDK wizard, not the PIM. Yeah, the wizard wasn't great. Also, it was slow since every file assembled had several megabytes of headers included.

Having C code running on the watch is nuts. The builtin ROM software was written in a high-level assembler (probably for size/CPU/power consumption reasons), and the user SDK was a regular assembler (I got the impression that back then Epson wasn't giving away the better development software, so the best that could be included for free with the SDK was the regular assembler.) The OS's overlay system and semi-adhoc calling convention isn't C friendly. Often, values were passed in whatever registers were convenient for the callee, with macros to help hide this when possible. EEPROM access functions took parameters from global RAM variables.

The SDK documentation was great. 10/10. You could not reasonably ask for more. It had many examples, every single header file used by Timex, which documented every single function and variable (even ones internal to the builtin software), and PDFs describing every bit of data going in and out of the watch, from the communication protocol to the file formats used by every builtin app. The OS used by the watch is impressively clean and easy to use for a one-off 8-bit system.

Most development for the watch was shared on a Yahoo Group, which is down now, but there are backups somewhere. I manually saved a bunch, and I know that people there backed up the messages and uploaded them to... I don't remember exactly where, I'd have to look it up. I remember running across a post there from the EEVBlog guy when looking through old posts. He was asking about making a fitness tracking app.

It took me a long time to get around to writing anything for it, but I wrote several programs for it around 2013-2015ish. A timer, calender, expense tracker, and a viewer for the user tracking data (stuff like how many times you've pressed a button, entered an app, or had an alarm go off). The SDK had a single DOS program as part of the build process (it was something to feed the linker some addresses), so I had to rewrite a 32-bit version to get the SDK to work on 64-bit Windows 7. I think I later found someone else already did that on the Yahoo Group.

A society can do multiple things at a time, and it's a more efficient use of resources to do so. Progress made in an activity versus resources put into it is generally logarithmic or even asymptotic when investing extreme amounts of resources, so if you have a huge amount of resources to spend (like a country does), you can get more done in total if you spread them out a bit instead of focusing on one thing at a time. Sticking another billion dollars into fixing housing would have a negligible difference. Finding solutions to something like that requires experimentation, data gathering, and deliberation, which all take time. Putting people on the moon will not affect the passage of time for those of us on Earth. (And it hardly affects the passage of time for anyone on a rocket, as well.)

>C was designed to let compilers have a field day so that 1980s supercomputers could get 5% more FP performance, by hook or by crook.

C was designed to help create Unix. It just happened to turn out to be something that could be compiled into more efficient code than most other languages at the time, without being overly difficult to work with.

From what I understand, 80s supercomputers were more likely to run Fortran. Fortran has fewer problems with pointer aliasing than C, so a Fortran compiler could generate better code than a C compiler for the type of code they would be running.

Explaining the joke/reference:

https://www.youtube.com/watch?v=lsgnrYog6W0

I didn't make StrongForth, I just based my own Forth on it. I've really only used it in my game engine.

Might not be quite what you're thinking of, but for typed Forth, there's StrongForth, which is statically typed. I wrote a Forth-based scripting system for Dreamcast homebrew, and used StrongForth's type system in it. I would run and edit the scripts live on the console, and the static typing was a big help to prevent errors that could crash the system (since the game ran under a single process, and did not use the MMU).

https://www.stephan-becher.de/strongforth/intro.htm

Does this have the Nintendo logo in the ROM header? Real GameBoys check the ROM for an image containing Nintendo's logo during boot up as a way to prevent unlicensed games. The idea is, to make a GMB/GBC boot, you must at least commit trademark infringement, which gives Nintendo more legal leverage to block/punish any attempts to sell anything that Nintendo didn't get a cut of.

If the logo is missing, it would still boot on an emulator that doesn't emulate the boot ROM (which is most of them) and probably most flashcarts, so there's no need for it to be in their release. But it's still possible that whatever build system they used automatically inserted the logo.

There's no way Nintendo would bother McDonalds legally over something like this if the logo's in there, but I'm still curious if it is.

I'm adapting QOA to the Dreamcast for streaming music. I've modified it to use 32-bit little endian values instead of 64-bit since (besides avoiding having to byteswap) the CPU in the Dreamcast is badly suited for 64-bit shifts.

For converting a "slice" from the 64-bit format (which is has a 4-bit value in the highest bits, and 20 3-bit values organized from high to low. Each 3-bit value is read from the high to low), I treated it as two separate 32-bit values. The bottom two bits of are combined to get the 4-bit value, and the rest contains two pairs of 10 3-bit values organized low to high.

So this:

  sample = (slice >> 57) & 0x7;  //Get sample
  slice <<= 3;  //Advance to next sample (64-bit shift)

Became this:

  sample = slice & 0x7;  //Get sample
  slice >>= 3;  //Advance to next sample (32-bit shift)

I think the conversion to 32-bit little endian was something like an 8-10% speed up, with no other changes? (This was a few months ago, and I didn't write down what the exact difference was.) The overhead big endian conversion and 64-bit shifts would become even more noticeable after further optimizations. (Replacing qoa_lms_predict with inline asm to use an integer multiply-accumulate instruction that GCC can't generate got something like another 20-25% speedup. Properly written asm would be even faster.)

I loathe things "magically" disappearing and reappearing. I want a predictable, consistent interface. I can work faster when things are consistent. Scrollbars, besides allowing me to jump around in a document, give me an indication of where I am on the page. When I ask, "How much of this page/window/document is left? About where am I in it?" (a common question) the answer should be RIGHT THERE and not unhelpfully hidden/unavailable or difficult to see. I shouldn't have to waste time fighting to find out.

If someone from Framework is reading this, page up and page down are among my most used keys. Having to use an extra hand for something so common is crazy. I absolutely will not buy a laptop or standalone keyboard without dedicated page up and page down keys.

Ideally, page up and down will be next to the arrow keys (look at a Thinkpad keyboard), but off to the side is still better than not existing.

StrongForth (http://www.arestlessmind.org/2009/02/03/intro.html) is a statically typed Forth that checks (and requires!) the annotations. It traces how the stack changes after every operation, and guarantees that every function is passed the correct number and types of parameters, and leaves the correct parameters on the stack when it returns. It's impossible to underflow the stack, and overflows are as likely as in C/C++/etc.

To do this, there are some limitations on how the stack can be used compared to regular Forth. (For example, both sides of an IF/ELSE must leave the same number of items on the stack with the same types, but they can have different values. An IF without an ELSE can never change the depth of the stack or what types are on it, since the implicit, empty ELSE side says that the stack doesn't change.) This generally isn't a huge problem, as the things you can't do in StrongForth are usually not such a good idea from a maintenance perspective in regular Forths.

I did a bit of work on re-implementing SC2K years ago (it was going to be called "21st Century Micropolis") that never got much further than creating asset rippers, a city viewer, and researching into how the simulation works. Nothing playable.

I did discover a semi-easter egg in the newspaper. One paper has an opinions section, and there are two possible lines that have fixed names (both are in the list of tax complaints):

  -fred Haslam:  "I just *[0x7f] to say, property taxes are primitive, repressive and regressive. only barbaric societies continues to tax the rich."
  -pat Mullanney:  "you bet I mind! I feel like the *mo's got a gun to my side, robbing me of MY *[0xb9]."

Fred Haslam was a programmer on SC2K, and was also credited for being one of the newspaper writers. I'm not sure who Pat Mullanney is.

There are a few homebrew releases that used WinCE, but that makes up something like 1% or less of homebrew software. I think there was some MP3 player, a 3D FPS that was never released, and a Duke3D port? Maybe a couple more? KallistiOS is, by far, the most popular choice, and is used in probably 98% of homebrew.

That really seems like something that should generate warning, when a value assigned to a size_t was cast to a type smaller than size_t from a value that was as >= size_t.

  size_t v;  //64-bit size_t
  v = (unsigned)0xff00000001;
  printf("%zu\n", v);  //Prints 1

I don't get any warnings for this on GCC 9.4 or Clang 15.0.4 with Wall+Wextra.

If you wanted to deliberately do that kind of cast, for some reason, you could prevent the warning like this:

  v = (size_t)(unsigned)0xff00000001;

The light gun used by the arcade version of House of the Dead 2 (and I think Virtua Cop 3 and Ghost Squad) also worked the same way as the Wii Remote's pointer, using a camera in the controller to sense infrared LEDs. So the screen doesn't flash white when you pull the trigger on the arcade version of HotD2 like it does on the console version.

Instead of a single bar with two LEDs like on the Wii, there's a row of five LEDs above and below the screen. You can make them out in this video:

https://youtu.be/vmt-UAc28bo?t=192

I replaced the batteries on my three US Dreamcasts earlier this year. Each one had a different sized battery.

My VA0 revision console, with a date code of July 1999, had the largest battery with a Sanyo ML2430. My other two were VA1 revisions made in March 2000, and one had a Maxwell ML2032 and the other had a Panasonic ML2020. (With coin cells, the first two digits is the battery's diameter in millimeters, and the last two is the thickness in 10ths of a millimeter. So a 2032 is 20 millimeters wide, and 3.2 millimeters thick.)

Apparently, Sega of Japan planned for a US$299 price point, but Sega of America wanted to sell it at $199, so SOJ ended up doing redesigns on the internals to bring down the manufacturing cost. I guess using cheaper batteries (whatever they could get a hold of, screw consistency) was one way they did that.

Eh. I really don't like the majority of 2D Mario. I find that Mario games are only somewhat enjoyable the first time though, and get even less interesting if you try to replay it. The good Sonic games are enjoyable the first time though, and get even better on replays.

My earliest gaming that I could really put time into (ignoring stuff like playing SMB3 for a bit at a neighbors' house, or PC games like "Gizmos and Gadgets") was the Mario Land games on Game Boy, and the 90's Sonic PC ports (Sonic CD and Sonic 3&K), and those are still the kind of level design that think is the best. A 2D level should have variety, every part should be memorable and unique, and it should want me to play it again.

I hate the normal 2D Mario level design style (SMB1, SMB2J, SMB3, SMW1, and NewSMB series) because so many 2D Mario levels feel like they take one obstacle, then use some procedural generation to repeat it any pad out the stage. Too many scroll purely in one direction, and lack interesting secrets or alternate paths.

Mario Land 1/2 and the Genesis Sonic game levels have landmarks and parts with obstacles or layouts that were totally unique or only repeated once, so you knew for sure where in the level you were. One of the first levels in SMW is just a bunch of spinning platforms in a row. If you were shown a short gameplay clip of that level, could you tell if that's the 3rd, 4th, 5th, or 6th spinning platform? Probably not, but there's only one place in Green Hill with a checkpoint between two s-pipes, so you'd know exactly were in the game that is if you saw it.

With SMB1, the repetition and one-way level design is understandable, due to technical limitations. But it stayed with Mario, and even in the New SMB games, many levels emulate the same, boring linear style.

Besides the Game Boy Mario games, Western SMB2/Doki Doki Panic and Yoshi's Island have good, interesting levels. The GBA and DS Sonic games' levels are poor because really fail at having good landmarks and the levels feel same-y.

In Mario Land 2 you could find secret exits that would lead to entirely new levels. Sonic levels have paths though the level that are more difficult to stay on, so you want to try again to see what you missed when the first time though. Sonic 1 may have levels like Marble Zone that don't really fit the idea of going fast, but they're still interesting and enjoyable if you look past that, far better than the average SMB3 or SMW level. Other 2D Mario games did have some exploration in bits, but it wasn't has good as Land 2 or Sonic.

Also, the ground controls for console 2D Mario kind of suck (the air controls are fine, though). SMB1's controls were good compared to other games of the time, but they've aged poorly and don't really fit the game. If you want to move at a decent speed, you have to hold B all the time for some reason, Mario's acceleration is too low, and I guess he greases his shoes considering how he decelerates. The Game Boy Mario games have much better, responsive controls than the "normal" 2D Mario games (but you still have to hold B, though). Sonic has the spindash, so he can accelerate fine, and his deceleration feels right.

I've wondered if my opinion of the Genesis 2D Sonic's was because I had played the games so much because I didn't have other options and I learned to accept any flaws. I wasn't a fan of spindash-less Sonic 1 at first, but when I tried hacking the game and ended up replaying parts of it a lot, I started to appropriate it more, so maybe repetition was a part of it? But later then Sonic Mania came out, and it was exactly what I thought I wanted, I enjoyed it as much I thought I would.

It was only Phantasy Star Online that used Beats.

I wrote and tested SuperH assembly on the Jornada. The 32X and Dreamcast both use a SuperH CPU like the Jornada, so if the assembly works on the Jornada (baring some instruction set differences), it works on the others.

In particular, one thing I worked on blitting code for the Jornada and 32X. It would draw directly from RLE compressed graphics which would save RAM and speed up some operations. Like if there was several transparent pixels in a row, it could skip over the pixels in one go and instead of having to read each transparent pixel, compare it to the transparent value, then skip over it.

I have a small collection of Windows CE devices (https://imgur.com/a/Mn15nab) because a few years ago I wanted something pocket sized with a physical keyboard to program on (I use a Comso Communicator now). All of the ones I have are ones with a SuperH CPU.

The Jornada 690 palmtop, with a 133 MHz SuperH-3-DSP and 32 MB of RAM, is my favorite and most used, since it has a good Linux distribution (although fairly aged now). I've used it to help develop code for homebrew 32X and Dreamcast projects (I don't have to upload the code to anything when I want to test it, and GDB is a lot more reliable when you have memory protection).

The Compaq Aero 8000 is a laptop similar to the WorkPad, but it has a 128 MHz SuperH-4. The SH4 gained superscalar execution, 50% more cache, and an FPU over the SH3, so the Aero is actually significantly faster than the Jornada despite the small clock reduction. (IIRC, PDF rendering would take about 50% more time on the Jornada) The display is a 800x600 passive matrix LCD, but it has static image quality on par with an active matrix LCD, with none of the smearing you'd expect... however, the ghosting is still pretty bad.

The Aero 8000 has 16 MB of RAM built-in. It has a SO-DIMM slot for more RAM and can be upgraded to 64 MB, but when I found RAM that worked, I only got half the amount. Apparently, some GPIO lines are multiplexed with the memory data lines, so using the GPIO limits you to a 32-bit data bus instead of the full 64-bits, meaning half the 64-bit PC100 SO-DIMM was unusable. When I got a working 128MB PC100 SO-DIMM, I was able to get it to recognize 64 MB of RAM. (The Dreamcast uses an SH4 variant that multiplexes GPIO with address lines instead.)

I don't understand what the advantage of an expansion card that sticks out like that is over using something external on a cable.

The main point of the self contained expansions is that you are unlikely to loose them and they can safely travel around with the device. With a card that protrudes like that, if you want to put the laptop in a bag, you have to take the card out, or risk damaging the card and/or laptop as the protrusion gets levered around. The expansion cards plug into USB-C connectors that are soldered directly onto the motherboard, so the risk of damaging the motherboard though the expansion card does exist (although it's probably not that likely, and any damage would probably be localized to just the motherboard's USB connector).

With a external Ethernet port, you can have the USB expansion card in between the motherboard and the USB Ethernet device, to prevent wear on the motherboard's connector when repeatedly connecting and disconnecting the device.

So what's the gain by using the expansion card format, when it can't permanently live in the laptop? You might as well just use a cable. I guess maybe if you only carry the laptop by hand and have to constantly use Ethernet, like if you're debugging a network installation, it would be good? But a regular USB Ethernet port seems like it would be more practical for most cases.

A quick search shows that LOADALL can only be run from ring 0, so the same might be true for STOREALL. So ring 0 kernel could use STOREALL to return to real mode, but ring 3 user code would probably get an illegal instruction trap.

For some kind of write once archival storage, it would probably still have a use. But with flash that fragile, I'd be worried about how sensitive to read disturb it would be.

The reason no one would accept the 999999/1 split is because it is a terrible choice from an evolutionary perspective.

You're getting pretty much nothing while your genetic competitor gets a huge advantage. This is not rational. Natural selection would cause the genome of people who accept this split to be less likely to survive.

Accepting only even splits helps select for cooperation. If your neighbors are more likely to work with, share, and help you and your children, your DNA will be more likely to survive.

>had half the VRAM removed at the last minute

I've never heard anything suggesting that video RAM was removed. AFAIK, the SNES was planned to have only 8KB of main RAM, which was increased to 128KB by release. I think any support for 128KB VRAM was for future proofing, like if the SNES's hardware was reused for arcade systems, or something.

Source: https://www-chrismcovell-com.translate.goog/secret/sp_sfcpro...

The Genesis's video chip can support 128KB video RAM as well, which besides allowing a larger variety of tiles on screen and doubles DMA bandwidth. It was used in the System C2 arcade board. The Genesis was originally designed to use 64KB video RAM, but after hearing about the SNES, support for 128KB was added. Then they decided that the extra RAM didn't make enough of a difference to justify the cost, so they left it at 64KB.

Source: https://readonlymemory.vg/shop/book/sega-mega-drive-genesis-...

Install FFUpdater, then you can use that to install Brave.

The CPU in the PlayStation is nowhere near a 90 MHz Pentium.

The CPUs in the Saturn, PlayStation, and N64 were single issue, and could execute at most one instruction per clock. The Pentium was superscalar and could execute two instructions per clock. The Pentium would likely average, for integer operations, more than four or five times the performance. Much higher for floating point.

The MIPS CPU in the PlayStation is much closer to a 486 in performance-per-clock for general purpose code. A similarly clocked 486 might win some G.P. code competitions due to better caches, but the PSX's CPU would smoke the 486 in transform and lighting, thanks to it's DSP coprocessor, and the MIPS would still have much better performance-per-dollar than the 486.

There's some activity on the mailing list.

I think the main problem is that the mutation rate and transfer rate of memes is still optimized for tribal settings.

Most mutations are disadvantageous, but if you never mutate, then you can never improve, so you need some mutations to make progress.

Meme mutation rate would be influenced by the structure of the brain (i.e. how likely a neuron is to misfire or make random connections) and meme transfer rate would be influenced by instincts (i.e. how likely a person is to trust another or go along with their idea). It's possible to influence these after birth through teaching, but genetics would still play a significant role this, and genes are generally very slow to adapt.

Just a few thousand years ago (a microscopic amount of time from a genetic view), it would not be possible for humans in one part of the world to quickly spread ideas to another. If one caveman tribe develops a disadvantageous meme mutation, it's mostly limited to that tribe. That tribe with the poison meme might die out, but there are other tribes that can still exist as backups for humanity. There might be that there's a little bit of genetic meme recklessness in humans that took advantage of that for faster development (some memeticly reckless tribes got lucky and grew). But with modern, connected society, meme spreading behavior that relied on that failsafe can now threaten every human.

It will probably be several thousand years before things get better, assuming we don't drive ourselves to extinction.

I just tried it out, but it doesn't work the way I hoped it would.

I was hoping for some kind of SIGSTOP equivalent on any JavaScript when the tab doesn't have focus (without unloading anything). Instead, it basically closes the tab but leaves it on the tab bar, and when you return to it the tab gets reloaded.