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.