Cramming Solitaire onto a Nintendo E-Reader card
127 points by retro_guy 7 days ago | 42 comments
  • retro_guy 7 days ago |
  • davexunit 6 days ago |
    This was a great read, the debugging substory in particular. I bought the unpopular E-Reader as a kid and felt pretty ripped off by it. If only I had known there was a z80 emulator inside. ;)
  • mouse_ 5 days ago |
    impressive!
  • relistan 5 days ago |
    I live deep dives like this into something obscure and cool! Looks like fun
  • a1o 5 days ago |
    Does someone knows what the Mosaic E-Reader API call does?

    ``` RST8_26h Mosaic ;bg<n>cnt.bit6=a.bit<n>, [400004Ch]=de ```

    • unleaded 5 days ago |
      If you search for the address 400004Ch on https://problemkaputt.de/gbatek.htm it leads to the mosaic control register. It does a primitive pixellation effect (no averaging or anything, it just holds the top left pixel of the region) on a background layer. The exact same effect is present in the SNES and DS and is often used for level transitions. I don't know enough Z80 to know how you use the API call though.
      • a1o 5 days ago |
        Thanks, I remember this transition in Super Mario World. Nice to have a name for it.
  • ndiddy 5 days ago |
    Great article! I think the tiny size of the cards, the Z80 VM, and the high-ish level "scripting" API make the E-Reader a really interesting platform. I might try writing something for it if I ever get around to it.
  • palsecam 5 days ago |
    > A single E-Reader dotstrip can store 2,192 bytes of data, which is just over 2kb. But there is some overhead with the headers […] data on the dotstrip is compressed though

    > In the end I didn't need to do too much space optimization to keep Solitaire down to two dotstrips

    So, a full implementation of Solitaire in ~4KiB. Count me impressed!

    I like to show off that my own (as a web app: https://FreeSolitaire.win) is "only" 21KiB, but that’s small fry in comparaison!

    • stavros 5 days ago |
      > "only" 21KiB, but that’s small fry in comparaison!

      Or, rather, big fry.

    • redundantly 5 days ago |
      > You finished in 6 min 32s and 118 moves.

      > 118 on your own + 0 hinted + 0 to auto-end.

      > The computer could do it in 117 moves.

      I've played a lot of solitaire over the past four decades, one of my favourite versions was on the HP 620LX. I'd like to think I'm just this amazing, but it feels like it was too easy.

      What kind of shuffling does your program use? Do you start off with easier decks to entice new users to keep playing or was it just pure chance that I got such an easy shuffle?

      In any regard, I like your implementation. Worked extremely well in Safari on iOS, that's an accomplishment on its own, it's rare that web based games work as well as yours did on mobile.

      • bongodongobob 5 days ago |
        It's easy because you're drawing one card at a time, not 3.
        • codezero 5 days ago |
          There’s a setting to change that :)
        • redundantly 5 days ago |
          It was significantly easier than other 1-card draw implementations I've played. I wonder if the logic used to ensure the game is winnable causes a bias towards easier shuffles.

          Still fun, though!

          • w-ll 5 days ago |
            It did feel easy but i play quite a lot of solitaire.

            I won Solitaire game #456491 in 3 min 39 s, 126 moves. Beat me if you can: https://FreeSolitaire.win/turn-one#456491

            > The computer could do it in 129 moves.

            seams i beat the computer

      • palsecam 5 days ago |
        > What kind of shuffling does your program use?

        The shuffling is random, but only winnable decks are generated (by default). The computer algorithm/solver is described here: https://FreeSolitaire.win/strategy

        So it’s pure chance you got an easy shuffle.

        > In any regard, I like your implementation.

        Thanks, I’m glad you like it! If you have suggestions for improvement, I’m all ears (here or by e-mail) ;-)

      • mormegil 5 days ago |
        Yeah, I don't think I'm an expert but... > You finished in 6 min 17 s and 122 moves. > When including undone moves: 123 in total; 103 on your own + 0 hinted + 20 to auto-end. > The computer could do it in 122 moves.

        Unbelievable. But I agree, it's very well done!

    • bluepizza 5 days ago |
      This is fantastic! You packed great playability, interesting insights, and made a fun game, more than just a small one.
  • whamlastxmas 5 days ago |
    Super cool, I love this!
  • yincrash 5 days ago |
    Reading this, it seems like the Z80 emulator is a Gameboy emulator and the quirks that the dev was finding with the Z80 emulation was due to it not really being a Z80 emulator?
    • Dwedit 5 days ago |
      For comparison, SMSAdvance has a proper Z80 emulator.
    • JonathonW 5 days ago |
      Is it even an emulator? There's an SM83 (the Game Boy Color's weird not-quite-Z80 CPU) hiding inside the Game Boy Advance's SoC.

      [edit] Reading a bit more, it is an emulator-- and apparently an inefficient, poorly-written one at that.

      • lxgr 5 days ago |
        The original GBA models (including the SP) did actually feature a Sharp SM83 (the Z80-compatible CPU used in the GB and GBC) for GB/GBC backwards compatibility.

        It was never accessible by GBA games (or at least intended to be accessed, so to my knowledge no official titles did), and so the Game Boy Micro and the DS and DS Lite, which both feature GBA but not GB/GBC backwards compatibility, could drop it without causing any problems for GBA games.

        • Dwedit 5 days ago |
          GBC mode (with the z80-like processor) cannot be accessed in GBA mode at all.
        • mmaniac 7 hours ago |
          The Game Boy Micro still contained a useable SM83 and GBC PPU on the SoC, but the cartridge is inaccessible. In theory you might be able to run a tiny payload from WRAM (32KB?) but it's pretty useless otherwise.

          https://github.com/AntonioND/gba-switch-to-gbc

  • tsujamin 5 days ago |
    I used to _love_ the E-Reader, and had a huge stack of cards for it.

    It was neat that it integrated into so many different games. I think my favourites were playing NES ExciteBike and the Pokemon Ruby/Sapphire/Emerald trainer cards.

    The E-Reader is only surpassed by the GameBoy Camera.

  • testplzignore 5 days ago |
    But can it run Doom?
    • egypturnash 5 days ago |
      A single E-Reader dotstrip can store 2,192 bytes of data, which is just over 2kb. But there is some overhead with the headers, and error correction, making the actual amount of data I've been able to store on a single strip a bit less than 2kb. This data on the dotstrip is compressed though, which helps a lot.

      The E-Reader itself allows a maximum of 12 strips to be scanned for a single application.

      You'd have to fit your Doom into about 24k, after compression. The Doom 1 demo .wad looks to be about four megabytes. That's going to be a slight problem, I hope you have some killer compression schemes.

      This Solitaire port is also running on a Z80. An emulated Z80. On a Gameboy Advance. With a bunch of opcodes missing. That'll be a challenge too.

      The Gameboy Advance that this card reader works with can run Doom, there was an official port. It looks acceptable. (https://www.youtube.com/watch?v=YzGwAKUXzvU)

      If this E-Reader can run its programs on the GBA's native hardware then you only have to implement some amazing compression schemes. Good luck beating Farbrusch's Kkreiger (https://www.pouet.net/prod.php?which=12036), that's a procedurally-generated FPS that fits in 96k...

      • ForHackernews 5 days ago |
        He says an eReader app can be loaded in up to 12 individual card-swipes, so you could get ~26kb. He just tried to limit himself to a single swipe.
        • gambiting 5 days ago |
          He limited himself to a single card not a single swipe - it still needed two swipes.
        • Uvix 5 days ago |
          One card, which is two swipes.
          • egypturnash 3 days ago |
            Oooh, that means you've got about twelve kilobytes to fit your Doom into. Or your bootstrap routine that connects to some other device connected to the Gameboy Advance and downloads your actual Doom. Whether or not this counts as "running Doom on this device" is open to argument.
  • dmitrygr 5 days ago |
    The “weird crippled z80” is the GB/C cpu which is indeed a z80 with some things removed and a few added.
    • ndiddy 5 days ago |
      It's fairly similar, but the Gameboy CPU supports a few opcodes that the E-Reader doesn't (DAA, HALT, DI, EI) and the E-Reader has a few custom opcodes (there's a couple for waiting a specified number of frames, and a couple used for API calls). I think it's better to say that both are 8080 supersets.
  • Narishma 5 days ago |
    Why do they say it's running on a Z80 emulator? Doesn't the GBA have a Z80 CPU (or rather the SM83 variant) to run GB and GBC games?
    • jasonjayr 5 days ago |
      The ereader device has a [limited] z80 emulator.
    • Uvix 5 days ago |
      It does have one, but it's not accessible when running in GBA mode.
    • lxgr 5 days ago |
      The original GBA (and GBA SP) did, but the Game Boy Micro and DS Lite didn't.

      At least the latter is apparently compatible with the E-Reader.

  • msephton 5 days ago |
    Love this! And love what they did with ERAPI. Do we know specifically who created that?
  • Dwedit 5 days ago |
    With compression, elimination of dependencies, and the THUMB instruction set, would a version written in C have fit on a single card?
  • raymond_goo 4 days ago |
    here is a nice Yukon solitaire variant, that is guaranteed solvable. https://www.solitairle.com/
  • mmmlinux 3 days ago |
    Really wish i knew where my E-Reader wondered off to years ago. maybe one day it will show up again. I think about it time to time and wondered about the programming challenges it must have had.