brpocock

I actually like the mobile ports of Zuma and AstroPop, and play them both frequently. AstroPop in particular is a good time-waster disclaimer: I had nothing to do with those ports, but there's some kind of incest here as my employers did the IFE ports.

Hm... secondary? Probably Panasonic DSEBi (3000i)</a> ... As for home systems, the GCN wins hands-down. edit: oops, bbcode, not html

OK, now, I understand the objection during VBLANK, as there's game logic running concurrently and it's extremely difficult to get the timing right on that sort of code. But, why would it bother overscan?

In redoing some "far call" text subroutines I suddenly realized I was waay over-engineering things. (C=128 users will recall how bad the KERNAL ROM far call routine was? Yeah. That bad.) So, I needed to crib together my module organization anyways, so here it is for posterity. Most of the modules are major game modes/screens. They're modal, and basically "jump/goto" one another, so I don't need "subroutine" semantics. Their communications are entirely through the player's persistent data (i.e. "game data" v. "temp data") or the "linkage area," which is a static area (currently 8 bytes) which follows the player data in every module. Each module arranges the rest of ZP above a "certain" mark to its own liking, so we zero it on bank switch. Shared ROM The bank-switching code is very stupid and lives near the top of every ROM (duplicated). It basically just switches to bank (.x) and then jumps to that bank's "entry" label. (Currently those are all at $f000, but that's not necessary since the bankswitch is recompiled for each bank.) Some modules share memory banks. In that case, I use a flag in .y to indicate which module routine I want to invoke, and the "entry" routine dispatches accordingly. The only currently-used "far subroutines" are for text decoding, and the Ursa interpreter, and they're special-cased with entry vectors in the shared ROM area. Finally, wedged in before the main bank-switching code is the RES vector routine, which forces a bankswitch to bank 0, module 0 (CLEAN_START and attraction) Major Modules The major modules of the program are: The Tile Drawing aka Transit, Travel, Map kernel The Combat kernel Attraction/Winner mode Conversation mode The Stats displays Save/Restore game routines Tile Drawing basically takes "player_map" and "tile_xy" values to decide (a) whether the data for "player_map" is in the current bank (if not, guess whether to bankswitch "up" or "down" and try again); and (b) where to place the player. It then runs full-tilt, calling Ursa ocassionally to handle script events. SELECT jumps to Stats, RESET jumps to Save Game. Combat has a fairly involved set of timers and "turn-taking" - basically each of the player and each monster get a turn broken down into an idle period (the monster is "thinking") or menu selections; then, the attack animation; then, the results of the attack. Like the Tile kernel it just needs to know how many monsters and what type, and then "searches" for the bank capable of handling that type of monster. The background artwork is tied to "player_map." Attraction mode is a series of "mini kernels" for doing various bits of the animation. If someone wins the game there will be some animations there, as well. Conversation mode is basically just a scrolling text display or an interactive menu display. They're mostly the same, except when they're not. Because of ROM limits there may be multiple conversation banks to handle the quantity of text. Stats display is broken down into several "subscreens." Interestingly, we can call Stats from any bank, so it tries to work from within a limited size stack space and some linkage area temporary variables, so as to not corrupt the "caller's" data. The Save/Restore routines are bit more -- strange. Some of it triggers Ursa menus (Conversation views), but the main screens are: View Code ("Save" Code) Enter Code ("Load" Code) Enter filename for new file (nickname for new player) Choose filename from list of those on the MemCard Rule #1. You can't save using a code unless you're on the map. (Too much is happening to save the state using a code.) Rule #2. You need a filename to save to MemCard (or AVox). Since this would smash the combat variables, you can't save to a MemCard during combat unless you already have done so. Let's presume also from conversation, then. OK, weird enough for ya? Possible situations: Player has no MemCard. Code save is accessed from RESET and from Stats. Player has a MemCard, connected when in Attraction. s/he starts a game, and is prompted for a nickname/filename. The MemCard block is allocated. Save can happen (almost) anywhere now. Player has a MemCard, but not connected until s/he starts playing. Since we didn't see it up front, we don't let him/her try to save until on the map. Then, s/he gets prompted whether to create a file and/or view the code. Played had a MemCard, but removed it. We just prompt him/her to re-insert it. If s/he refuses/cancels, we assume it's gone and go back to the "no MemCard available" state. If it's inserted, we look for the "splat" (open-for-writing) file on the card and proceed just as if nothing had happened. Player removes the MemCard during play and inserts another. Now, this is a problem, because the player's name data was stored on the MemCard in a "directory" area! So, we treat this like a "lost" MemCard, above. Note that the "directory" marks the active file and tracks filenames. In CBM DOS, we called "open" files "splat" files, because the DOS marked them with a * beside their names. (And, if you saw a splat file in BASIC, it was a pretty sure bet that something had crashed while writing the file, unless some machine language "wedge" was writing to it right as you loaded the directory file.) If we see a MemCard from the main menu with splay files, we'll need to validate their checksum(s), and if they fail, delete them Oh, right... basic checksums. Something really basic, maybe CRC or similar. Incidentally, to keep people relatively honest, there'll be some checksum bits in the screen codes, too.

Wouldn't hurt to ask. Of course, they might well have bought them through a wholesaler if this was a limited production run, or something. Being curious, I checked... US PTO never issued any trademarks similar to "men a vision." I couldn't figure out how to check biz licenses in California, though. Assuming (wildly) that the company was in California, or even USA. I doubt, say, Mexico or Brazil has such records online

Probably too many WSYNC's as placeholders in the vblank, but the combat kernel (still sans major improvements blogged earlier today) rolls my B&W test TV. (A 12" "LLOYDS" branded NTSC.) The 11" colour set -- a more modern (early '90s) Panasonic set -- displays a fine and steady picture, but it would be more tolerant of bad signal, being more recent. I think. Note to self: adjust timing of vblank to use INTIM* rather than just throwing a shitload of WSYNC's in there. PS: Note[2] to self: buy another EPROM, I don't think that leg is going to grow back (It's been years since I pried one of these babies off, sorry baby... lucky I bought a spare before, but still sadness.)

Some time ... late '80's, possibly early '90's, there were a series of adverts. At the time I was subscribed to several game and computer magazines, so I don't know the publication, but it was a glossy colour print, not newsprint inside. At least partly. These particular adverts were each on two pages, quarter-page ads. On the first page would be a harmless barnyard animal, cartoon illustration, with a "Dick and Jane" "Captain Obvious" caption... "Polly is a sheep. Polly says, 'baa.' " On the second page following, in the same quarter-page space (like a flip-book), would be the same animal, anthropomorphized slightly into a superhero or villain of some kind. "Polly likes to dress in leather and humiliate cattle" with the sheep in a bustière looking like The Poodle de Sade. I've lost the scans of the ads and can't recall the title. Anybody else remember there? PS: Yes, this was an advert for a videogame.

This has a lot of merit. On www.serpo.org, the contending theory is that the "Roswell" crash actually did not take place in Roswell, but rather in two seperate locations in other New Mexico towns. One of those towns just happens to be Alamogordo. The reason we can't find the missing carts? Totally because of the alien colony coverup (they've got good in the last 50 years at passing for human!). -JD It occurs to me that Albuquerque was the home of part-time code thiefs and part-time reputed Solicitation defendants Traf-O-Data for a while. The next thing you know they've brainwashed IBM into giving away their kingdom. Hmm. Maybe not so good at passing for "human," after all.

film students. They need practice pulling permits ... and every small town loves free publicity. Skip the lawyers, get some film students and turn them loose on the Chamber of Commerce. (A few hot Production Assistants never hurt either.)

I'm about 60% satisfied with the Oak-Mitsui (possibly pre-merger) explanation, but, supposing the word isn't "oak," it could be any word beginning "oak" or "oar" in that font I only get 50 dictionary matches without starting into proper nouns, though. If it's any of them I have to hope it's "oaktongue." There's an interesting word.

Where do you see that? Partly cropped at left of the reverse (trace side) PCB photo; and echoed again under the traces near the top.

I'm curious about the 2-player rumour. I do have it on good authority that it's a networkable game. You know, Wiis are small - very portable, and relatively cheap, and have built-in wireless. This could be the best improvement they could make on a party game like this. How to improve on Smash Bros. Melee projected on a giant tarp on the side of the garage with 7' tall characters? Why, 2 giant tarps, and the TV in the living-room, linked to some guy in Singapore...

Completely uninformed random information: Hitachi has a partner company (unclear relationship) named Oak-Mitsui. www.OakMitsui.Com says: Oak-Mitsui™ (OM) specializes in the development and production of world class performance copper foils, Aluminum Bonded Copper (ABC), and Advanced Interconnect Materials (AIM) for electronic interconnect (printed circuit board) applications. Headquartered in Hoosick Falls, New York, with locations in Camden, SC, and Riverside, CA, Oak-Mitsui is a subsidiary of Mitsui Kinzoku Corporate Group, the world's largest manufacturer of copper foils for electronics. Plausible?

Sadly, I read that about 3 times before realizing the connection. Amazing how I can put the blinders on, like that.

got little-to-nothing done on the game last night... but did have a verbose eMail exchange with Mayday nailing down most of the inventory stuff. The combat attack animations are also starting to sound pretty good. Coded but not tested (OK, not even merged back in) the smooth movement for the player on the tile map. I'm a little nervous that freaky mad wiggling the stick left and right (or up and down) could accumulate some "error" drift where the player won't "land" on a tile squarely, but no real harm can come of it, so I'll scrimp on ROM for that. Doing tile-based and sub-tile moves is actually pretty nasty business. I have a TODO spike solution to see if tracking the movement as strictly screen-based, and then translating back to tiles, will shorten the ROM routines any. Complicating things is that testing for overflows and underflows takes an obnoxious number of compare-and-branch tests (luckily underflows can use beq or bmi depending on context, but overflows pretty much always require a compare). Combat mode animations are shaping up. It's a little tricky because I have to do animations across five different "rows" (subprogram chunks) in the main field area, and some of them are keyed to various temporary data. For example, when the player gets hurt the "how many HP did you lose" display needs to levitate in a certain place. Conceptually, I use a two-byte timer, one byte is animation_timer which counts deciseconds, one byte is frame_timer which cycles 0..5 (NTSC) or 0..4 (PAL/SECAM). For the purposes of transient animations like player/monster attacks and the like, I started sprinking individual countdown timers all over the place, but now I'm starting to think that it can run full-tilt off the animation_timer. Whenever the player makes his (her) inputs, and the game starts "running on autopilot" fora while, I can just zero both timers. Worst-case is that the animations could "skip" up to 5 (NTSC) or 4 (PAL) frames, or, that idle animations of the monsters could flip states back to animation frame 0 suddenly. Hopefully, the player would be so distracted by pushing the red button that s/he wouldn't notice? Alternatively, I might create another decisecond countdown timer and do the shared timer thing with it, rather than abusing animation_timer. That's probably the route I'll start off with, as it's easier to merge from it back to the single-timer code if I decide it sucks, than to seek-and-split the single-timer code. But the dozen or so independent timers are just dumb. Text-handling... I've got a nifty but evil piece of glue code to eliminate duplicate fonts! Yay. It does smash a lot of ZP RAM, but, as it turns out, I was being too paranoid about RAM. Imagine that? I actually had some RAM "left over." Kinda. Tile drawing kernel has (above its stack/tempvars requirements) 2 bytes still free! Combat kernel (without some of the animation code and some of the input code enabled) hit zero earlier, but the new text handling and some rethinks of how to handle colour lookups for monsters solved that quickly. Back-of-envelope answer is that with all the code re-enabled, some timers eliminated, and Ursa(*below) turned on, I should have 20-odd bytes free. Oh, yeah, monsters are Ursa-driven now. I decided that most of their attacks were pretty basic and found ways to do some black magic. The Ursa routine basically drops a "trigger" code that gets picked up to run the animation and precompute the end results. That means "high-level" (ish) combat routines so I can pass the buck to Mayday on fine-tuning the figures there. (By "high level" I mean, um, almost as bad as assembly, but much slower. ) So, some "architectural" level puzzles sorted out. Oh! My stack problems are an off-by-one lookup in the map table logic, and when I nudged that by -1 some constants I broke something that depended on that off-by-one. Maybe tonight I'll get some time to examine that further as well as to check out the stack glitch/table glitch. And, line (7,2) still bites. I haven't really taken a knife to it yet. We'll see.

Yes. Apparently when it's actively doing reads/writes the AVox/MemCard can be dis/re-connected at whim. (It could probably survive a "read" disconnect but your cart might flake?) And/or, you could have multiple "file slots" on one MemCard, as well. Named critters, pull up a menu like, LOAD CRITTER? COOKIE ZELDA RHINDLE NE146 ---- (unused slot)

It's a pain, but it's doable. The code gets progressively longer the more data you need to save, and it takes a bit of overhead if you don't already have text-handling routines and such in your program. I'm using the RESET switch for it on CiE... tap RESET, then the code appears (and I'll save to a MemCard if present) and you would need to choose "QUIT" from a menu... on the theory that you wouldn't ever actually want to be dumped back to the title screen without saving. Just because it's kinda scary to pull the RESET switch, though, in CiE it's also an option from the in-game menus (If using a 32-character alphabet, say, A-Z and 0-5, you get 5 bits per character, so to save all of RAM (128 bytes x 8 = 1024 bits) would take 205 characters edit: 205, but the 205th has a few bits free, bad math)

The Three Ducks!! (from Adventure, of course.)

While we're at it... "breakpoint at (pixel/cpu cycle per scanline)" would be icing. (Having spent the past two days making sure PF2 updates and HMOVE's happen at Just The Right Cycle...)

Last night's efforts. Ignoring the rest of the screen, which I've blocked out for the moment, notice that these trees are drawn "perfectly." Every PF2 hit is exactly on cycle, and the HMOVEs also. (There's an HMOVE on every scanline, but always at cycle 73.) The rest of the screen is fouled up because my "bad line" (triplet 7 line 2 on each row, i.e. scanline 24 of each 24-scanline row) is still not cleaned-up. Now that I have the timing "perfect," though, I can try to re-arrange some of the tasks from 7,2 into the SLEEPs in other lines I actually have an 8-cycle sleep that I completely lack understanding as to why it's needed... but hey, if it works, it works. It has to do something with the interleaving of 24-line rows, 8-line x 3 playfield graphics, and 12-line x 2 player graphics, and my total discomfort in working with figures. To get the timing right I'm afraid I used the "tube of toothpaste" method. "squeezed" in extra SLEEPs on line (0,0), then (0,1), then (0,2), working my way up to about (2,0) before the other lines snapped into place (excepting (7,2) of course). Ironing out the joystick code tonight and possibly augmenting the sound code slightly. A musician friend of mine (thanks Natalie!) saw some animatics I'd sketched out and noticed my use of musical repeat notations - ||: | - and the discussion reminded me that I could maybe support such repeats in the sound code to compress the music better. The combat kernel is mostly intact on my iMac, I've got to merge it back into the Subversion fold though. The kernel (notably) lacks some major functions, notably: there are no animated attacks yet (horrors!)... the attacks have no actual effects (HP/MP aren't changed)... and monsters don't animate individually. (All monsters on screen animate in lock-step. You know... NUSIZ clones.) Oh... and equipping items/magic doesn't work through the UI. I've been tweaking ZP locations in Stella, which is probably not the best UI ever. Ursa's basically done, tile drawing's almost done, combat kernel gets some TLC next and then I get to point at Mayday and take a nap for a while. But instead I'll probably hack up some cool magic and attack animations and work on stuff like the stats display (easy, but annoying), the save/load game code for Avox/memcard (where did I stash that MemCard during the move!?), and the attraction mode and "you win" animation sequences. I've toyed with the idea of giving Ursa some controls to do "Macromedia Director" type animation controls, like, "move P0 in a line to location (x,y) doing alternations every (n) deciseconds between bitmaps (a) and (b)" to do the attraction and winner kernels and possibly (gasp!) a cut scene? ... but that kind of candy should probably wait. It depends on whether I think I can pull it off more easily using Ursa or 6507 assembly... and which takes less ROM space. BTW, don't think I "blogged" this before, but all animations and fx are based on a decisecond timer. Unfortunately I did have to go for NTSC/PAL conditional compilation. The NTSC version naturally has 6 frames per dsec, the PAL,SECAM version only 5, and the music generator "mksound" -- which is abyssmal, right now, I really should work on it, too! -- writes conditional-compilation AU* register triplets out. Also, all colours are registered with conditional-compilation NTSC v. PAL colours, and the SECAM colours are used as the B&W values. This does mean that if you trip the B&W switch on the console the screen will look kinda trippy on colour TV, but, it'll be playable on a B&W set. Aside: I was playing another author's homebrew on my B&W test set and was brutally murdered by invisible enemies on about the 4th level, not realizing that their colour was nearly the playfield colour Of course, I may be the only one who'll ever see "CiE" on a B&W set... Hey! it's "colourblind mode!" There ya go. I knew it was practical. Oh, nearly forgot: here's the goodies!

Apparently I have only an old copy of the combat code here, because it hangs after drawing one frame

This is me tuning the bad lines. See the missing pixel in the forest? Center of screen, where PF2 is about to reflect itself. naughty, naughty pixel. The pink "spots" are a decoration. Decorations on the map exist at 12x8 px per tile, i.e. they're drawn using P1 at double-clocks and 2 line resolution. (Tiles themselves are 4x8 pixels, using 4-clock-wide playfield pixels times 3 lines resolution.) Later on they turned into a cheesie picture of an house. Then, something disrupted .y during my main loop and blew everything to Hell. The player actually is drawing, here. His feet are messed up by a bad line though. That was a really really dumb rendition of a tile floor or something. Oh... see? colours (per row) are back in. Now I use the stack, too. At last check I had 15 bytes of free memory, but I know some of that is wasted. (That includes "padding" for all the players "stats," btw.) I'm leaving a few things split off into different ZP locations that aren't used at the same time just to make debugging easier. Tonight's goal: fix up the timing with the colour and decoration code back in. If that's completed before midnight, maybe try to marry the bank switching code back in and see if the combat, conversation, and Ursa interpreters can co-exist. Or maybe un-comment all the joystick code. Hint to future players: scripts on the map are triggered by P0/P1 collisions. So, to enter a village, walk into its icon, to talk to a person, smack into them. No surprises there, I'm sure. Hint #2: controls breakdown: Joystick: walk around, scroll text, select from menus. Trigger: select from menus mostly. On the map: enters the "combat screen" with no enemies so you can equip items/spells. Reset: "Save game?" prompt. Will give you a nasty code to re-enter or look for an AtariVox/MemCard to write to. Select: Stats screen. Difficulty: sets handicaps for attack/defend in combat. Color/B&W: does what it says it does. Power: does what it says it does So, it's mostly intuitive but there is a painful mental leap to think, "if I pull the Reset switch it won't kill my (hours?) of progress, but instead will let me save it!" I'll probably put a link to "save" on the stats screen too. That will hurt my soul less.

I'm just gonna dump status reports to my blog for now... this thread has gotten rather unmanageably long and the blog format's probably better suited to ongoing status reports anyways.

Probably a C=128. Compatible with the C=64 were the 64C -- just repackaged in a lighter beige, more "modern" late-80's package; the 128 -- much larger, more wedge-shaped, and had a 100% C=64 mode (hold down the C= key during boot) as well as a native mode with dual processors (MOS-8502, compatible with the MOS-6502, and a Z-80A) and dual GPU's (uses a composite monitor or TV for the first display and the sound, and a standard 9-pin EGA-type display for the other) that was capable of running native C=128 software or CP/M apps; and the 128D -- the same as the 128, but with a more "PC-style" form factor, detachable keyboard, and built-in disc drive. I often say I'm a C=64 fanboy, but the C=128 was really a powerhouse machine. 128kiB RAM, expandable to 16MiB, dual CPU's, dual GPU's, SID sound (with popular third-party add-ons for stereo sound aka "dual SID mode"), light pen/light gun, joystick, paddles, keypad, mouse ports compatible with the Atari, "high-speed" serial (up to 19200 b/sec), and "smart" storage devices (the DOS is on the disc drives; they're basically "network attached storage" on the IEC serial bus). I have to share my EGA display with my Tandy 1000 though they're kinda hard to come by these days. As for Ultima and Bard's Tale... all good stuff. You can playtest 'em on VICE if you've a Linux box, it runs pristine C=128 emulation.

In case anyone's watching ... Re-introduced colour code and came up with some nice optimizations based on the "tiledraw.o" test. The current test kernel in that series, "tiledraw3.o" is coming along. One annoyance? branches in the P0 draw routine taking a hit for the carry in PC (i.e. crossing a page boundary) may require some of my sleep nop's to be replaced with page alignment spacers. Keeping that working will be sheer Hell. Theory: if I need to add some bytes but not cycles to get alignment without changing timing, pad out a few nop's but do a "guaranteed branch" over it, probably by doing something like bit rows_left; guaranteed to have high bit clear bvc .skip_align nop nop nop nop nop nop .skip_align:; The Hell will be keeping the page alignments and cycle counts both correct. Thank God I'm doing this in M4 and can easily re-sort which scanlines in each row things are going to happen. For your entertainment, here's the latest build's echo outputs on RAM/ROM usage... player_data_start $80 player_transient data length $3 player_data_end $99 player_persist data length $17 total player data length $1a linkage_data_start $9a linkage_data_ends $a1 linkage_data length $8 sounds (6B) at $a2 tiledraw_data_start $a9 tiledraw player data $a9 tiledraw decorations data $b0 tiledraw boards data $b6 tiledraw rows data $bb tile data and prefetches $be tile bitmaps alternating buffers $c6 tempvars (may be eliminated in production!) $ce reserved stack space for row data pre-pushes $cf tiledraw_data_end $ee tiledraw data length $46 End of RAM allocations $ee Total RAM used $6f Free RAM for stack $11 ROM bank 0 begins $f000 Setup begins $f026 Frame draw begins (with VSYNC) $f03a vertical sync space preamble ends $f043 beginning game animation and input $f043 Prepare to draw rows $f261 end of game logic $f26d length of main loop $22a Row drawing begins $f282 Straight-ahead drawing ends $f6ca length of unrolled drawing $448 End of kernel $f6de end of bank 0 code $f6de length of bank 0 code $6de Start of bank 0 data $f800 Start of lookup tables area $f800 End of lookup tables area $f829 Lookup tables' length $29 Start of bitmaps area $f829 player_art $f829 end of player art $f865 decorations $f900 end of decorations $f919 tile bitmaps $f919 reversed tile bitmaps (PF1/left, PF2/right) $f941 end of tile bitmaps $f969 number of tile bitmaps $5 verifying bitmap ROM usage: $5 OK, computes end of bitmaps data $f969 length of bitmaps data $140 start of maps data $fa00 end of maps data $fa81 length of maps data $81 end of bank 0 data $fa81 length of data $281 *** Appendix Area: *** The appendix area ends at: $ff15 The length of the appendix area is: $15 The appendix area is the bank-switching code that's dummied-out in this build, it normally will end at $ffee when using the final EF bankswitching.