Cramming Solitaire onto a Nintendo E-Reader card | Hacker News Reader

Cramming Solitaire onto a Nintendo E-Reader card

mattgreer.dev

127 pointsretro_guy43 comments

> 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!

> "only" 21KiB, but that’s small fry in comparaison!

Or, rather, big fry.

> 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.

It's easy because you're drawing one card at a time, not 3.

There’s a setting to change that :)

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!

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

> 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) ;-)

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!

This is fantastic! You packed great playability, interesting insights, and made a fun game, more than just a small one.

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.

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?

For comparison, SMSAdvance has a proper Z80 emulator.

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.

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.

GBC mode (with the z80-like processor) cannot be accessed in GBA mode at all.

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

The “weird crippled z80” is the GB/C cpu which is indeed a z80 with some things removed and a few added.

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.

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?

The ereader device has a [limited] z80 emulator.

It does have one, but it's not accessible when running in GBA mode.

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.

If you think this is cool, then check out this guy that made additional dlc for some of the pokemon games that had new items and events distributed by dot card: https://youtu.be/fgX36SAeTwQ?si=p5YXONlbbAHW1mLe https://youtu.be/6j4CfGlHFI8?si=Bento62buP6g974z

It's pretty cool as he covers using the internal api that the pokemon games implement to handle the dot card data as well.

I live deep dives like this into something obscure and cool! Looks like fun

Source: https://www.reddit.com/r/retrogamedev/comments/1gglfqx/cramm...

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.

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. ;)

Does someone knows what the Mosaic E-Reader API call does?

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

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.

Thanks, I remember this transition in Super Mario World. Nice to have a name for it.

Love this! And love what they did with ERAPI. Do we know specifically who created that?

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.

With compression, elimination of dependencies, and the THUMB instruction set, would a version written in C have fit on a single card?

Super cool, I love this!

here is a nice Yukon solitaire variant, that is guaranteed solvable. https://www.solitairle.com/

But can it run Doom?

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...

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.

He limited himself to a single card not a single swipe - it still needed two swipes.

One card, which is two swipes.

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.

impressive!

Reply on news.ycombinator.com