Bruce-Robert Pocock

Each of the areas has its own 4k bank, with 50-75 screens and its own musical theme. So, in theory, that could add another 3 maps — but, realistically, one additional 4k region + 8k for additional text/scripting perhaps.

For the utterly curious, memory banks assignments are about like: Bank 0: Cold Start/title, EEPROM (SaveKey/on-cart) access Bank 1: Map mode services and the Failure screen Bank 2: Text services Bank 3: Province 1 maps (Port Lion) and music Bank 4: Province 0 maps (Treble Village, Anchor, Spiral Woods, &c) and music Bank 5: Province 2 maps (underground areas) and music Bank 6: Combat Bank 7: Sound effects, speech, and music drivers, and title music Bank 8-12: Text, scripting, and speech Bank 12 (also): End of game Bank 13: Lots of random bits stuffed in at the last minute Bank 14: Monsters (stats, graphics, names) Bank 15: Animation services, combat services, and game finale code As far as the “glyph based” communications system, maybe take a little peek at the games Dungeon and Dungeon II here on AtariAge, they use a not-entirely-different system…

It looks like the total data for phonemes runs about 8,120 bytes (give or take a few), and there's a little bit of code that goes with it — the printed text totals around 6,461 or so bytes itself. (The text panels are lightly “compressed” in that each character takes only 6 bits, so there are actually about 8,172 characters plus some control codes like colors and scripting.) Overall, with the scripting engine code (replicated in each bank) there are 6 banks of text and speech data × 4 kiB each — one of which is also used for some end-of-game graphics and such as well. That's a total footprint of about 24kiB for text, speech, and drivers; removing the speech portion would probably remove not only 8,120 bytes of speech, but also compact the number of banks needed for the text, so it could get maybe packed in to about 3 banks (12k), freeing up 12k for whatever else might be interesting.

Let me run some figures and I can tell you about the size precisely, but in general, the speech phonemes I think are similar in size to the visible text. I did a thing like that once upon a time (Orpheus for PC-DOS), but later saw it done well — in Mass Effect. The player chooses the “attitude” of their response rather than specific text …

I wasn't sure if I'd missed something. Unfortunately the source code is “just’ conditionalized on the TV standard — so there would be quite a bit of work to isolate the bits relevant to the sound or colors vs. the timing. (Incidentally, we're amidst moving house, so I won't likely have time to do much of anything but that for a few weeks.)

There is a PAL 50Hz version available (as well as SECAM 50Hz) available; is that not commonly supported now?

A progress (or lack thereof) update. So — the project is not abandoned (far from it), just had to be tabled as other things came to the forefront of my "non work" hours. Since 12/2 there's been a couple of family events, in addition to Channukah, Christmas, New Year's, and now the rather involved process of moving from Florida to Oregon tying us up, so there have not been any major updates. To be honest, I haven't even been able to keep up with AtariAge nor the ZPH shows, much less get time to troubleshoot race conditions and display list corruption, unfortunately for Phantasia's progress. (For what it's worth, we've bought a house in Portland and are going to be there full-time in just a few weeks, so there's packing and getting the Fort Lauderdale house ready to sell and … and … and … all happening at once.) All that being said, it'll most likely be March before my “around the new year” prediction of a demo build is even plausible. It will happen! — eventually. Sorry to disappoint anyone who might be waiting for this, but "A delayed game is eventually good, a rushed game is forever bad." (Miyamoto)

Just wanted to share that @TIX has kindly joined up with us and contributed already some new art for the player-character Here's a rough take of him running around in the game engine with a shield equipped As a general update, I have what I think is a race condition happening (for you programmer types out there) between DLI-NMIs and the main thread (which is using a primitive cooperative multi-tasking mechanism) that causes display list corruption and lockups. The goal is still to get a playable walking tour of one area together around the new year, with those problems solved.

It definitely was strongly influenced by them as a whole. It actually began it's evolution as a party-based TRPG concept I was calling "Initial Fantasy" for no particular reason 😏 but pretty quickly the "monster collector" genre took over. If anyone we're ambitious about doing "Initial Fantasy" it's still quite possible that the Grizzards code would make a nice starting point, but even with SaveKey that would probably require more ROM and SARA RAM to complete successfully. By the way … I have been meaning to finalize a public build based on the cartridge version and should have that packaged up in the next couple of weeks, in time for the general release in the AtariAge store. It's mostly just packaging work, ensuring the PDF manual matches the public build of the game, and general administrative type things: the code is all in place for it. I've been trying to hammer out some technical hurdles on Phantasia that have kept me from circling around to that lately.

Thanks for doing the inglorious sysop work that keeps everything running smoothly! PlusCart is an amazing tool for developers.

We are happy to say that @Pac-Lander has graciously agreed to join our team (with myself and Zephyr Salz) to assist with writing, level design, &c. We're hoping to have a little proof-of-concept demo around the new year time frame; not much more than a test level that you can explore, really, but something in relatively playable shape.

I always say, most folks who re-invent the wheel end up with an octagon.

That's great, I'll be reading that in more detail soon. I started an implementation based on DEFLATE but ran into just garbage output, with the added “fun” that I can't really tell if it's the compressor or decompressor at fault, but I'm sure something better than RLE will be the final goal. Y'all's collective efforts w.r.t. LZ4 look quite promising there! That particular pain point I'm pushing off until the initial demo map is working, though, as running out of ROM for the demo should hopefully not be A Thing.

A couple of folks have reached out with some questions and I found myself writing a too-detailed message late the night before last, much of which I thought might have a little broader interest: Lots of Stuff About Tools With Grizzards I spent several months creating (or updating) some toolchain elements before reaching a playable demo around June 2021 — 15 months later, in October 2022 (about a week later than it should have bene), it was finally done. Phantasia is still leading up to a playable demo, and mostly crashing. However, a lot of the tool chain support is either already in place, or in the works. I'm a firm believer in using existing tools wherever possible, so I've spent a good deal of time building up the framework for asset importers for the game already. Stamp graphics of all kinds are imported from png files, with palette indicator swatches in the lower margin; they're brought in either as tilesets from tsx files from Tiled, or using simple bundling for other graphics like fonts and decorative UI elements for the status area, e.g. one block of ROM is packed with the 8×8 font, some UI drawing elements, and the “sad face” from the crash screen: Hopefully nobody else ever “gets” to see this screen, but it's in there… There's also a separate “blob” (as in “bitmap large object block”) importer used for e.g. the title card that rips everything into display lists for a fixed screen; some work is still needed to make that animation-friendly, though. (The title card currently has no animation per se.) The maps are brought in from tmx files from Tiled, and contain the base layer tiles, alternate tiles for some things (e.g. destructible objects), placed objects for decals (e.g. the signs that say “SHOP” and “INN” here, or the coins near the player), enemies, NPCs, shallow or deep water, animated base tiles, climbable surfaces, &c. — basically anything I can get away with using Tiled to do. (Please disregard the palette error on the SHOP sign, I haven't worked out what I've done wrong there, but it's on the list of bugs.) As you might imagine, that means I make pretty hearty use of “custom properties” in Tiled. (Also, everything looks a bit “squashed” in Tiled since it assumes square pixels and 160A/B mode does not have those.) Right now, maps in ROM are compressed using a super-simple run-length encoding that rewards you for repeating, adjacent horizontal spans of graphics, but I hope to work in a better quality compression algorithm. The [non-player] characters are mostly constructed by applying colors to a figure made up of compositing heads onto bodies, although I do probably have the opportunity to also introduce a handful of unique character designs for very special characters. Their scripting will be (this does not work at all yet) using a pretty simplistic scripting “language” based upon the format teleplays/screenplays are usually written in (fountain files) with some specific rules about the stage directions and such. A test script that won't appear in the game that I'm using for testing the script parser looks like this: You can see the branching logic for the player is buried in the parentheticals which normally would indicate something adverbial about how the actor is meant to deliver the line. The music should be coming from MIDI files, but I haven't gotten much into the MIDI→HOKEY/POKEY converter yet; it's going to be based on an improved version of the MIDI→TIA converter from Grizzards. I'm using the spreadsheet by @Synthpopalooza as a data table to drive the conversion routine, but it needs a good amount more work yet. (It currently seems to think that zero-note polyphony is the limit, rather than four.) We do rely upon MuseScore3 for MIDI editing, but potentially any MIDI editor could be usable. And, finally, the data tables for a lot of game attributes are straight-up coming from ods spreadsheets: these include mapping frames from a “sprite sheet” to the player, or an enemy, or an NPC; assigning enemies stats like HP and damage amounts; assigning item drops to enemies and destructible objects; assigning stats to NPCs; and assigning items to shops. Again, basically anything that would be easier to work with in LibreOffice than a text file is going in there. The whole build system is F/OSS, and the compiler tools are designed to be moderately friendly to a non-programmer designer, so with a little initial set-up someone can pretty easily make changes to the design files (maps, graphics, scripts) and build a new a78 file to test without knowing much about the code, although I haven't tested anything to see how it would work on a non-Linux system yet. All the parts are nominally available on macOS or Windows, with varying degrees of difficulty to install them. The current build time going directly from make clean to time make test (running unit tests in the A7800 emulator) is 3m35s, which is pretty much the same time expected for make emu to start the emulator in debug mode. A ridiculously long amount of that time is spent in the very dumb RLE compressor for the maps (just the base map seen above takes 27s to compile), although the “BLOB” importer for the title card &c is also stupidly slow (1m22s for that title card!) and probably just needs some gentle optimizations or memoizing some functions. Unfortunately, changing any of the “large” assets (maps, scripts, music) causes the asset allocator to re-run, assigning assets to ROM banks to find an optimal layout, which means rebuilding much more than should strictly be necessary, but I'm fighting to keep the total build time less than 10m for the full game if possible. Again, none of these importers are very optimized so there is room for improvement. “Dev Journal” By way of “dev journal” I think the following are the major tech. hurdles that are still under weigh — I've kinda intentionally “front-loaded” the heavy lifting work, so once the game reaches a playable demo it “should” (I know, dangerous word) be more straightforward coding and less “solving technology hurdles” to progress: Scrolling is just misery right now. I think I'm perhaps using the wrong pointers sometimes and causing arbitrary corruption to display lists that are then modified again at the next scroll and multiplying the error until everything is wrong. Nobody said scrolling would be easy, that's why it's front-loaded. There is no animation of “tiles” in the game yet, but the compiler is yanking the animation information from Tiled and embedding it — I just have to come up with a somewhat effective way to use that information. NPCs require the script compiler, which means me remembering how to write a yacc grammar properly. The music compiler (MIDI→HOKEY) is far from working as well. I may defer this to after getting a silent demo running. The script compiler is in purgatory, because I actually have never written a lexer/parser for something as “Markdown”-like as Fountain files and I'm doing it horribly wrong. (Using CL-YACC, if by some miracle someone here is familiar with it.) There are a few serious timing glitches with Display List Interrupts when certain routines take too long to complete, so I have to distribute some workloads differently to ensure that can't happen. Heavy lifting, all, but the first one is the most troublesome as there really isn't anything to look to for references since the display list structures I'm using are kinda unique to this game engine. In unrelated news, we finished the first draft of the outline for the entire game's script last night! I'm pretty excited about the overall story, but we're gonna keep it under pretty close wraps, so as not to spoil any surprises. I will reveal that there are five “real” endings in addition to “you died, game over” being planned

I'm currently packing all 16k with graphics, and just copying selected graphics (basically sprites) out of the DMA holes into RAM, but there really isn't a 1:1 relationship between what graphics are being displayed and what code I wish I had access to. I could probably put code or something else into the gaps, but currently the “over world” and “indoors” banks are designed with different tiles, decals, and enemies, and each is currently ~12k of graphics data and planned to be 16k each. I toyed with arranging it to be hole-free, but my rationale is something like this: there are a lot of animation frames for one enemy, but relatively few distinct enemies visible at a time. If I were to directly draw from the ROM an enemy — let's say a slime (spoilers! ), it has 4 animation frames right now, and each is 8×16px @ 160A = 32 bytes. But if I had to accommodate non-holey DMA, it would have to be effectively 96 bytes for each of those 4 frames, which is 384 bytes total rather than 128 bytes — in general, each frame balloons up 300%. Neither helps for the player or NPCs, since they're composited from pieces. (The player gets equipment composited on to avoid proliferation of parts, and most NPCs are colorized combinations of bodies and heads.) That part is just sheer awesomeness, actually. $4000 is before holey DMA and ∴ I do have to pad composited or copied sprites there, which has led to some really crazy RAM layouts for other things: I have basically got the first 12k of RAM set up where a certain part of each page is reserved for striping Maria buffers, of which of course the first and last 4k's Maria portion are all zeroes, and all the actual game vars &c are split up into the gaps between the Maria data. So: each RAM page from $4000-$6fff actually has a part reserved for Maria, and a part delegated out for whatever other purposes it's needed, which limits the uncompressed map data (including the tile map and its attributes, like palette, interactivity, &c) to the remaining $7000-$7fff region, which effectively limits the maps to around 1k worth of tiles — e.g. 32×32 or any other variation that adds up the same way. (The screen can show at least part of about 21×13 tiles at a time, depending on what's going on.) Each tile takes a minimum of 2 bytes, one for tile/palette selection, and one is an indirection to its attributes block. (There are other map data as well, rounding out the 4k block there.) I think the Dream Configuration would be to have something like: Maria sees a 16k RAM + 32k banked ROM; and Sally seeing the same sort of think as Superbank, with 16k RAM + 16k banked ROM + 16k fixed ROM, but ideally with some ridiculous amount of ROM behind it. With what little I know about hardware, I'd imagine someone could potentially go with a 1MiB EEPROM for the Sally + Maria data both, which would be driving “only” the six upper address lines to the ROM (and one address line to RAM). If you use the last bank ($ff) as the fixed bank for Sally, then you can make the programmer choose carefully between 16k banks for Sally and 32k banks for Maria made up out of the same range of physical ROM space. (The Maria banks could potentially start at any 16k multiple and just run for 32k, or could be specified in multiples of 32k, whichever was easier to implement.)

Thanks! I had been vaguely aware of this technique/hardware, but for my purposes the “problem” comes in that Sally and Maria may see different contents, but both switch banks together. During the drawing of the screen I'm basically “stuck” with $8000 pointing to a particular bank (which varies) for a certain set of graphics/stamps for Maria for that screen; this basically prevents me from running code anywhere but the fixed bank at $c000 while the screen is being drawn. It's also limited to 128k, which might be a limiting factor. I'm definitely not fixated on the current (Superbank) bank switching, but I don't know if Bankset will bring a direct benefit as it is today.

The way it's currently working goes something like this: The map is broken down into a base tile map, which uses indirection and 160A mode; each tile can have a distinct palette, with its three colors. Due to the limits of indirect mode, there are a maximum of 128 base tiles (8×16px) possible at a time. Using 4×8px tiles at 160B would also limit me to 128 tiles, but would quadruple the amount of RAM needed to store a map, reducing the maximum size of a map/region. In order to draw a full screen like this without overloading Maria, groups of tiles that share a common palette are strung together into a single display list instruction, which is precomputed when the maps are being compiled (and compressed). In addition, “decals” can be affixed at any tile position, which are normally also in 160A mode, with their own palettes. Due to restrictions of memory layout, this is also limited to 128 possible decal tiles at a time. These allow more detail to appear on the map than would be possible with just the tile set; for example, in the screenshot I posted earlier, the palm tree near the top-center is a pair of decals, which you can see cross both the beach and ocean tiles; the coins in the center-right are seen on top of both grass and flower tiles. Beyond that, most enemies (or unusual NPCs) are coming from their own tile set, also in 160A mode. This tile set has 128 animation frames available, which are copied into a RAM buffer to be displayed due to memory limitations. The player-character and human NPCs, however, are in 160B mode. These are also composited into a RAM buffer, but in a more complex way; for the player-character, this can mean equipment items (like the shield in the screenshot I posted earlier) being composited into place; for other NPCs, there is a system being built (but not working yet) that composites them from a collection of body parts and colorizes them appropriately. These are in RAM both because of the compositing, and to get around memory limitations. I do appreciate the 160B rendering, and you may be right that it would be more doable at 128×192. The map region of the screen is currently running at 160px width; the height, however, skips over a few lines at the top for the status area. The actual, “internal” size of the display area is a little wider and taller than the viewport, since a partial tile may be scrolled off the edge of the screen at a time. In a 128px wide system, I guess I would need to mask out some of the edges by plotting additional black boxes over each edge… The display system is sure to evolve, but I expect the above description will remain largely the same, as Holey DMA limits which areas of memory can be safely used for various types of graphics. I should probably point out that 128 × 8×16px × 160A (= 4px/byte) = 4kiB, which is precisely the size area that Maria can see between DMA holes at 16px height. This means that the base tileset and main set of tile decals can each occupy a DMA region in the same 16kiB ROM bank — the two such windows available, while the more sprite-like objects (enemies, player, NPCs) are copied into RAM that is visible between to Maria's DMA as well. There is, also, more than one tile/decal set, but as you can imagine, 16kiB ROM banks are relatively “expensive” in this scale of a system and I don't want to get too carried away. You may be interested to know also that the title screen seen above is also in 160A mode, in order to fill the screen without overtaxing Maria. I haven't ruled out adding some animations to it, as well, which are just about possible with the current display list system.

Thanks @Trebor! Interestingly, I was using more like a 1.6 ratio, I'll have to re-examine my assumptions there if 1.7 is more accurate! I mostly am doing the artwork in Gimp, which has a lovely setting to allow non-square pixels. (Set Print Size to match the desired ratio + turn off View→□ Dot for Dot) Unfortunately there will probably remain a little bit of vertical squashing for our PAL friends :"( as I doubt I'll have the opportunity to create distinct artwork for each region, so I'm focusing on getting the NTSC version “square”-ish. Dot for Dot mode: with Dot for Dot disabled (and Print Size set to about the right aspect ratio):

Thanks! I've kinda hacked that into something I can use directly (at the expense of dual-controller support, since I only need/want one) but I'll have to wait a bit before I can get my hands on a dongle to test it

Someone suggested I might want to cross-post this a bit, so folks may discover it through either channel: A little 7800 ARPG project that I'm working-on. I'll only likely update the thread linked above as it reaches a viable alpha/demo stage and beyond.

Wow, I missed this when you posted it (we were still in Portland) but that's great to see Thanks!

Some of you may have noticed on the AtariAge handbills handed out at PRGE, that on the back cover there's a list of games Coming “Soon.” One of those is Phantasia, so I guess it's time to start a forum thread, even though I don't (yet) have a playable demo. What's Phantasia going to be? Phantasia is a new Action Role-Playing Game (ARPG), heavily inspired by a certain popular series of 27 ARPGs from a certain game hardware & software company, in particular, the SNES entry in that series. In point of fact, my very first “real” game I ever had written was a sort of knock-off of the NES original of that series on the Commodore 64 (my game, I believe, having been lost to time), so this is a particularly exciting project for me. Game Play Features Explore the world of Aclypt to uncover mysteries and quests and, of course, save your village Support for ProLine & compatible, Genesis, and Joy2b+ controllers. One button for using your equipped item, the other for calling up an item-select screen. (Joy2b+ button III = pause.) Your shield operates passively: when you're not using another item, your shield is effective. SNES2Atari: A/B use item, X/Y item-select, Start = pause, Select = same as console Select. Console switches: Pause=Pause, Select=Save (or password?), Reset=Quit/Reset Support for SaveKey (or AtariVox) for saving progress. (Possibly: also a password system? if it's practical) AtariVox voices for dialogue Pick up and use various items of various kinds: equipment items (e.g. weapons), single-use items (e.g. potions), items that are used automatically (e.g. keys), shields, armor, and possibly some other things. Converse interactively with characters in the game world Defeat monsters. Solve puzzles. Technical Notes A map system that allows arbitrary palettes and action attributes for each tile as well as “decals” over them to provide more than the 128 tiles that would otherwise be available, edited using Tiled Graphics are developed in Gimp as PNGs and converted to Maria's awkward formats as appropriate. 320px mode for stats and text, 160px mode for the game play board Music conversion from MIDI; probably for HOKEY/POKEY. Thanks to @Synthpopalooza's spreadsheets for providing the tabular basis for my converter. Uses a 16k RAM addition for decompressing map data (which currently uses a cheap RLE system) I'm not sure how large it will be in the end, but “big.” I've written an allocation system for the larger assets (maps, music, scripts, &c.) to be packed into 16k ROM banks as efficiently as reasonable. Demo builds are being designed to work with the Concerto (as well as, of course, that it should work with emulators and Dragonfly, but Concerto is the lowest-common-denominator at the moment) What's Coming Up? First, I need to fix quite a few things that are badly broken to get a playable demo! Also, we'll definitely want some collaborators, particularly as regards to testing the game as we go along, but of course any input or suggestions are appreciated.

Actually physical release as well, at PRGE. Unless you're waiting for the November general release. If you want to get over specific, it's 64k ROM + 2k EEPROM for save records 😎

I've posted the sources for Grizzards at https://GitHub.com/brpocock/grizzards — but they may not be the most approachable thing, as it's a rather complex game. Always happy to answer any questions, however.