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