brpocock

I haven't really been checking in over here, lately, but if anyone noticed that the old Ursine Core / Skyline site went down ... I've moved the work-in-progress on Skyline 2600 over to SourceForge. Sidereal.net's server is still (apparently?) in the server farm waiting to be extracted from the flaming ruins, but this seemed like as good a time as any to dust off my TODO file and rewrite the kernel ... The project is at http://SourceForge.com/projects/ursinecore but I haven't created a real "web site" for it again, just yet. And, while I'm logged in here, "hello!" to everyone.

Sorry, I haven't been lurking on here often and only just noticed your comment. Yes, Skyline was released 21 October, 2007, with a simple set of levels that nobody much seems to have liked :'( There were also a number of critical bugs including handling of "bullets" from items used, occassional rolling of the screen due to the script interpreter running amock and taking too long to complete scripts, and I've personally been able to hang (or toss into an unplayably weird mode) the game a few times due to what I believe to be timing issues. So, the new version under development (there are downloads on the web site of Skyline 1.1 "alpha" release already, but it's basically just a test harness as yet) is being planned for a March'ish release. I've totally scrapped the game scripts and maps and am starting over with something a bit more "game:ish" than the walk-through from October. Unlike the "1.0" release party (in which I notably crashed the game on a 30-foot movie screen causing an ear-piercing wail until some wise soul unplugged the Atari), I'm not setting any hard dates on this release, largely because I am hoping to have some career-related news in February which may seriously impact my ability to make the March deadline. (Said news would involve relocation.) At some point, I intend to publish the bug tracker and Subversion repository for the game source code on the web site, but at this point, Skyline is very much a back-burner project that I throw some "spare" time at from time to time, and not something I'm working on daily. If you're interested at all in the ongoing status of Skyline 1.1, check out my blog on here or keep an eye on the web site, as I do upload binaries there somewhat frequently (although they're not much to write home about, at this point).

I'm so tempted to disassemble that... Must.. use... time.. productively... Must be a data table. O:-) LB = $B .ORG $0 0000 AF 55 AA .BYTE $AF,$55,$AA 0003 BA AA AA .BYTE $BA,$AA,$AA 0006 2A 5E C5 .BYTE $2A,$5E,$C5 000B LB = * + 2 0009 90 .BYTE $90

I know that practically nobody downloaded Skyline 1.0, perhaps because of the utter lack of interesting storyline, so while I have planned some code improvements for Skyline 1.1, the biggest improvements --- more game. More maps, more dialog, more character interactions. Total game-data redesign Throwing away the 1.0 game world and starting over Some characters/puzzle elements may be re-used, but totally revamped More text, less wasteful graphics The hoped-for changes: Do away with "missile stuck" / "missile loss" problems when using items (item-in-use sprites getting stuck or disappearing) Do away with "picture roll" due to Ursa script execution times -- I'm changing the script interpreter to have a timeout and interrupt scripts when it falls behind, rather than letting the picture roll. If the script interpreter falls too far behind, it'll even interrupt drawing of frames until it recovers ... Additional Ursa commands Additional compression of data sets (less spacing data) -- might also do a more highly compressed form for storybook graphics to save ROM Code improvements ... ? general performance Some administrative-type changes: New developers' web site with development Subversion and Wiki system (Trac) --- this will allow Skyline (and any offshoot projects that might crop up ... I have some awkward ideas in that regards ...) to share a public Subversion repository and bug tracker, general wiki. New authoring toolkit (web-based) --- allow game designers (not programmers) to enter data using web-based forms and get back a binary cartridge image --- this would involve a text editor and a simple pair of sprite/tile editors --- and be a massive improvement over the current ASCII forms. This is my #2 priority behind actualy bug fixes/performance issues in the code, as it will make it possible for me to do the additional design work. Stuff like picking NTSC, PAL, and SECAM colors for every tile are exceptionally awkward using text editors and look-up tables, and a nice EcmaScript application to do that stuff for me would be fantastic. Specific apps: tile editor, sprite editor, and map editor, and a general text editor for editing Ursa scripts. Thanks again for everyone's support, and hope 1.1 will be less of a disappointment to you all.

Tracked down a bogus hit on BRK (executing a $00 data byte) as the last culprit ... but sprite drawing time is still abyssmally wrong somehow ... I'm also vaguely suspicious that setting breakpoints in stella's debugger doesn't work as I think that it should, as I'm sure I'm missing some hits . . .

Haven't had time to really fix this up. There's an infinite loop inside the sprite handler, apparently incurred as a side effect of moving that subroutine into its own memory bank. The revised layout goes something like this: Banks 0 to 5 are map screens (game play screens); bank 6 contains sprite judgement/drawing-list creation, the interleaved (every third scanline) map venetian blinds code, and sprite graphics; bank 7 contains the Ursa interpreter, scripts, Ursa-injected bitmaps, text-drawing, and the status screen. I fully expect to shift that around a bit, such that bank 6 ends up being bank 7 most likely, and banks 0 .. n are map screens while n+1 .. 6 are Ursa banks. The Ursa interpreter, thank God, is flawless, but it's only running with the barest essential functionality, which (as it turns out) is sufficient for theoretically doing the main menu, simple NPC interactions, and NPC (monster) control sequences of the usual sorts, e.g. "walk toward the player without walking through walls." I'm working on a slightly more intelligent NPC script to implement a "right-hand rule" but really want to see the sprites actually functioning before messing with that any further. Besides which, the ursac rewrite was put on hold to get sprites done. The new parser is a bit more LALR and a bit more flexible in its string injestion, which is the more important part. String display is still basic 48px 12-column display; I toyed with 24-column and such and decided to KISS; there wasn't any real need for any of the game displays. Note that letters M, N, Q, and some punctuation are still double-column-width characters because I wanted legibility ... On the personal side, while I'm still ardently hoping to get this project released in a fully playable form in less than a month, the toll of having been beat up pretty good while breaking up an attempted murder two weeks ago, and the discovery yesterday that a friend of mine is on hospice care and not expected to be around many days more, along with all the usual madness of trying to juggle 3 jobs and an hobby like this, are making it sadly likely that a playable demo level might be all that's ready in time for the 30th anniversary :-( Nonetheless, I'm still rather proud of the architecture of the engine and hope that by year's end the Skyline game, at least, will be fully finished and polished. Regardless, I'm aiming to have "as much as possible" working perfectly in time for the 21st, and the release party will go on in whatever form the game ends up.

OK ... she fits. With no space to spare in the ROM, as it should be. Now, if she would also actually run after my latest hack-and-slash memory-bank re-org, I'd have something to show you, but I haven't :'( ... today (Thursday) I'll debug the bitch's sprite code Once And For All.

End of map data included endbank.s Regular straight-ahead ROM ends at $10138 Skipping ahead to bank switch code segment: bankers fed0 eqm vs current org: 10138 endbank.s (17): error: Origin Reverse-indexed. Aborting assembly Yeah. That's right. It doesn't effing fit. . . . I'll make it fit, damn it.

http://product.half.ebay.com/The-Legend-of...foQQprZ43856345

Almost there ... Allllmoooost....

The "15..20 Sept" release should happen this week-end with a playable screen, God willing. Real life interfered, as it has a nasty habit of doing. Ordered some blank carts though, for the debut party, so ... (knock on wood)

Indeed. As my deadline looms, this drawing-list stuff is increasingly getting marked as "features for the 1.1 release" and some sketchier but easier to debug stuff getting pushed into its place. :-( Imperfect code that mostly works is better than optimal code that mostly doesn't. Or something. EDIT: To clarify, that is: If you don't have time to debug, rewrite it more simply and save a draft.

There are now sprites. kinda. Except the drawing-list computations have obviously got a major error, because what should complete inside of 5 scanlines is taking more like 100 on (every other field?) And I'm pretty sure the drawing is incorrect inside the kernel too, but the timing isn't tweaked yet so it looks all sketchy anyways. Tonight I might get time to frell around with this properly. (Looks like one of those bpl/bmi stupid things that mess with me. Screenshot didn't catch the sprite field no matter how many times I tried :-( but there's a black rect flickering around looking like a trapezoidy thing in the midst of the crazy rolling.)

Began a major rewrite of ursac -- the Ursa script compiler -- some time ago. It's a lot cleaner code than the first go. It's also more practical for the type of game Little Dipper has become. It'll need reworking for Big Dipper, if that project ever flies. Among other things: Global default includes file rather than hardcoded enumerations (res/global.ursa) -- mostly just needed for defining global flags set File inclusion (include file. => res/file.ursa) Special binary modules supported: currently just for password-entry, everything else (so far) is stock for Skyline -- use module. do module. -- for example: use numeric_password_entry. do numeric_password_entry. -- The "use" declaration will be monitored by mkmk (Makefile generator), the "do" verb is an actual runtime command to call the exported method (ursa_do_$x) Syntax is more COBOLish than BCPLish now. Some example statements ... # these two are equivalent say: HELLO, WORLD. . # as: say "HELLO, WORLD.". # Menus... ask "WOULD YOU LIKE TO PLAY A GAME?"; for "YES", let_us_play; for "NO", you_are_boring. # Maths set my x to 8. set my reflection to true. set my x to player_x. set r0 to r0 + 4. # Assembly-type maths load r0. add 4. rotate left. rotate right. subtract 3. store r0. # Note that carry is cleared and ignored. # Flags. if my reflection is true, label_to_jump_to. if bit 3 of r0 is false, label_to_jump_to. set bit 2 of r0 to true. # Comparisons compare my x to player_x; when lesser, label_to_jump_to; when greater, some_other_label. compare r0 to 8; when equal, label_target. # bpl, bmi, bne, beq analogues. # zero test if r0 is zero, label_to_jump_to. # Object classes dispatch table class zombie: when hit, zombie_hit. when bump, zombie_bump. when lighted, zombie_lighted. when become, become_zombie. class done. # Invoking an object method zombie_hit: if friend is zero, zombie_hit_player. # ignore non-player sprite collisions done. zombie_hit_player: set player_hp to player_hp - 2. become zombie_attacking. done. class zombie_attacking: when become, become_zombie_attacking. when alarm, zombie_done_attacking. class done. become_zombie_attacking: set my reflection to false. set my graphic to zombie_attacking. set my timer to 1. done. zombie_done_attacking: become zombie. done. show picture skyline.png with caption: BY BRUCE-ROBERT POCOCK AND CHRISTOPHER BURLINGHAM . The ursac rewrite is back burner, but progressing, so hopefully some scripting capabilities of a minimal sort will make it into next week's "playable" pre-alpha.

The sprite judgement simplifications triggered by (among other things) trying to get a 6507 to divide by 7 repeatedly in VBLANK have begun ... The new judgement system is inspired by an "all or nothing" approach: either draw the full sprite, or don't try. I also got rid of the temporary drawing list expansion, and some more convoluted logic, by making the drawing-list into two byte-lists, one for a sprite index, one for a positioning code. During judgement, the positioning codes are Y values, afterwards, they're converted to X codes for RESPx/HMPx adjustments. The X values have to be recomputed as the list is being chained together, since they're all relative anyways. Here's the "first" draft of the new judgement code. $1 is 1 or 2 for each drawing list. (The subroutine/macro is expanded twice.) Note that a sprite could potentially be drawn on both lists, if it's very lucky, but that would mean there was nobody else who wanted that slot anyways. Also, there are any number of inefficiencies here, probably. Yeah, there are TODO's still -- I have to run in the middle of a rewrite :-( as usual. You (for certain values of "you") get the gist. sprite_judgement: ;; ;; Sprite handling: judgement code ;; ;; This is unrolled twice, with different postfixes to expand ;; it into drawlist1 and drawlist2. define({[MAKE_DRAWING_LIST]}, {[ subroutine ;; clear the drawing list ldy #DRAWING_LIST_LENGTH lda #$ff ldx #0 .clear_drawing_list: sta drawlist$1-1,y stx drawlist$1pos-1,y dey bne .clear_drawing_list if [ $1 == 1 ] ;; if this is an odd field, inject the player-character lda field_counter and #1 beq .skip_player lda #0 sta drawlist1 lda player_y sta drawlistpos1 ;; fall through and consider the first non-player sprite as usual .skip_player: endif ;; set the current search sprite to the next sprite in cycle, ;; and bump the start_sprite index. ldx start_sprite lda num_sprites inc start_sprite cmp start_sprite bne .start_ok lda #1 sta start_sprite .start_ok: ;; if slot 0 is open, claim it lda drawlist$1 cmp #$ff bne .consider_sprite stx drawlist$1 lda sprite_y,x sta drawlist$1pos jmp .consider_next_sprite .consider_sprite: lda sprite_y,x sta my_y ldy #DRAWING_LIST_LENGTH clc ;safety .walk_list: lda drawlist$1pos,y ;his position adc #8 ;his height in linesets cmp my_y ;; am I after him? then it's too late, since we're going ;; backwards, I don't get a slot here. bpl .consider_next_sprite ;; who's before him? cpy #0 ;anybody before? beq .try_to_claim dey ;; am I before the guy before? then I need to keep walking the list lda drawlist$1pos,y cmp my_y bmi .walk_list ;; I fall between the slots, that's good, let's try to claim it iny .try_to_claim: ;; We want this slot, but will we fit with horizontal repositioning? sty want_slot ;; Repositioning in scanlines -- 8px per HMPx or 48px per RESPx ;; Following sprite lda drawlist$1,y cmp #$ff beq .no_following tay lda sprite_x,y sbc sprite_x,x bpl .sign_ok eor #$ff ;invert to positive number bpl .sign_ok ;always taken .no_following: lda #0 .sign_ok: sta tmp0 ;the number of clocks by which to move, so far ;; TODO: make sure that this occurs before sprite starts ldy want_slot beq .no_prior dey lda drawlist$1,y cmp #$ff beq .no_prior tay lda sprite_x,y sbc sprite_x,x bpl .sign_ok_too eor #$ff bpl .sign_ok_too .no_prior: lda #0 .sign_ok_too: adc tmp0 ;total number of movement clocks ;; TODO: make sure this occurs before the following sprite starts .claim_it: ;; TODO: move up subsequent sprites in the list lda my_y ldy want_slot sta drawlist$1pos,y stx drawlist$1,y .consider_next_sprite: inx cpx num_sprites bne .consider_sprite .no_slots: ;; This drawing-list is full. Stop looking at it. ]}) EDIT: lda #1 after bne .start_ok -- don't consider the player-character, it's special-cased on odd fields. EDIT2: correct slot 0 claiming for new RAM layout

OK, already better than my attempts. I'm still mystified, where do you even get the ideas for these shortcuts?

In the interests of getting it to Just Work At All, I'm dropping this logic actually, but thanks to you both for many useful suggestions. My revised idea, rethinking a few things based on Thomas's comments on my blog, is to simplify the drawing list somewhat by only drawing a full sprite or not drawing it at all, which terribly simplifies the logic in the judgement routine, and the revised mess follows. An ideal divide by seven would make the judgement code more accurate, but I'm being pessimistic and doing a divide by eight, and possibly ruling out some slots which otherwise could have held sprites, in favour of more reasonable execution times, and the fact that my local time is 3:30am and complex math is never my strong suit to begin with. I suppose I could resort to a div7 table, as well :-( I think the valid range is only 0..49 or so, depending on how my RESPx hits end up aligning in the kernel, so at least it's a smallish table. Even smallish tables are starting to hurt me, though. I'll dump some things to my blog in a moment, rather than polluting this abortive thread.

This is actually for the "judgement" code to decide sprite drawing-lists ... I have the amount of displacement between two sprites to be entered into the drawing list, and am judging the number of scanlines required to perform the move. Incidentally, this is including a RESPx "shortcut" that allows bumping the position effectively up to 48 clocks (see my blog for details). I'm tinkering with pretending to move 8 clocks and then throwing in an extra count, which could taint the results, but it's just to decide the best slot in the list for a sprite, so I'm wondering if an approximation might work. The actual motion code works out something like the above; I (sometimes) hit RESPx (at one of two fixed positions) and then whack HMOVE until I think the sprite is where I want it. The judgement code rewrite has invalidated the sprite drawing in the kernel loop at the moment, so until I refactor that to match, this is all gut instinct.

Simple thing that's killing me. Any suggestions for a fast "divide by seven" routine? HMPx/HMOVE whacks give either 7 or 8 clocks of motion. Divide by 8 is easy - bit shift - but division by seven is killing me. I can live with doing a dex / sbc loop, but that isn't nice. Math and I are not friends.

Sprite handling judgement code is getting wacky. The judgement logic was sucking down too much RAM to compile ... so now I have an abbreviated version of the drawing list being used to set up sprites, which takes longer, and then expand it into the drawable version at the last moment, after doing judgements, and reusing the same RAM. Need to hack on this a bit more for it to generate a valid drawing list, and then implement the RESPx stuff. Just for fun, I frelled up something in the playfield logic and introduced one of those off-by-one errors that take forever to trace down, which means each playfield tile is being drawn out of phase by one lineset ... a macro run wild probably. EDIT/PS: OK, it's 3:30 AM in Florida, and I hate maths. So. Sprites either do, or don't, draw. None of this partial drawing stuff. I think Thomas's suggestion feels right about constant flicker, and in this case, all or nothing drawing is probably psychologically better. The "score" is no longer a score, since we just claim the slot or don't -- so I'm (ab)using cur_score to mean post-drawing repositioning lines. Sorta. Much optimisation will likely happen here shortly, in the mean time, here's the pig sty: I'll have to rethink the judgement code further, I almost posted it before realizing that it totally disregards realigning the temporary drawing list workspace properly and basically clobbers itself as it runs :-( It will probably be rewritten tomorrow morning while Chris is in class. For now, bed time.

I'm just pinging this topic in case anybody knows. :-( I never did find an answer.

Realistically, full-out bankswitching is probably fine for something of the 32k/64k scale, but I'd want a little more power for anything much larger than this project. An ideal layout for something like this (Skyline/CiE/Ursine Core) would probably include something like: 2k ROM (bankable) 1k ROM (bankable) 256B RAM as128B read + 128B write, (bankable) 64B FIFO stacks 64B FILO stacks 64B + 64B of stack retrieval registers for the above two 256B flash RAM (bankable) -- for saved game slots -- bank in persistant data, e.g. have page 0 be a catalogue/index and pages 1..n be individual players' save game slots 256B ROM at the tail for bank switching and reset vectors Of course, that would require some major fancy logic stuff, especially if the flash could be treated as RAM ... *shrug* But that's dreaming. I seem to think you had a super cartridge logic that could do things like this designed once, about 9-12 months ago? ... The 2k ROM could hold e.g. drawing code; the 1k ROM area the maps and graphics; the R/W RAM useful for various things, of course; the lists used for e.g. drawing lists and even preparing an entire screen's bitmap data and pulling it back down on the fly, which would be a godsend; the save game slots being mappable as RAM would make keeping persistent data a cinch; and the final ROM area would be unbanked since it mostly holds the cold start vector and some "jump to subroutine in bank x" code. Incidentally, having a caller stack in the FILO stacks would make adapting a C-type compiler much simpler ...

You just need to get the 64k logic for the PLD. I'm pretty sure AA has the hex for that kickin' around from back when HSR-RPG was forcasted to be 64k before it got canceled. I'd talk to Al if I was you to find out. ALSO: I can get you the larger 64k eproms for the same price as the 32k ones if you need. $50 bucks for 50 chips, shipping included. I actually found my Krocodile Kart, I might try a 64k test on it. I only have the 32k cart setup now (socketed EPROM) for testing. Al had once confirmed the possibility of making 64k carts. It's quite possible. But I definitely want something to show on the 30th anniversary and so forth, so it may be a de luxe edition that goes to cartridge production as 64k or something. I'm not brave enough around soldering irons for small work to try self-manufacture. As originally intended for CiE, Skyline will be available for AtariAge to carry if Al will do so ...

D'oh! Better. So, logic something like: If field is odd/even, inject player-character (sprite 0); Regardless as to whether that has happened, proceed to process drawing-lists starting from ( inc first_pick_sprite / bcc .ncar / lda #1 / sta first_pick_sprite ) ... That saves on figuring out where the player-character falls in rotation.

I'm working with 32k for the October version, mostly because that's the largest cart parts I can get prefab from the AtariAge store. If anybody has a 64k board and EPROM for sale, I still have time to expand the ROM budget. There may be a 1.1 release following the debut with some additional (game logic only, hopefully) enhancements, since I am more or less rushing this into production no-holds-barred.