2600 RPG - codename, "CiE"

[vdub_bobby]

...and the wolves come out...

[Robert M]

...and the wolves come out...

 

I am not a wolf! I am an ermine.

 

[Cybergoth]

Here in Augsburg we have Manules in the zoo:

 

 

[Bruce Tomlin]

Of course there's nothing you can do about Real Life, but I wouldn't mind seeing this succeed if only because of how it's being programmed.

 

I thought I was doing pretty good with a 60-cycle macro on every scan line for redbox/bluebox, but you could definitely say that the 2600 has been pushed to its limits when someone is using software to generate code for an 18-line kernel.

[Shawn]

So is this project shelved? I sure hope not. I actually had my hopes up for this one

[Godzilla]

i still remain optimistically pessimistic. :-) Really do hope this eventually has something to show. No time pressure tho, don't make deadlines kill you.

[brpocock]

I think there are some serious technical issues to overcome in trying to do that. Script generated code is notoriously larger an slower than hand written code.

 

Not necessarily. In this case, it's quite large, but by virtue of being larger, is faster. Only half-joking about it being an "18 line kernel" -- the loop is unrolled specifically to "work around" the lack of registers and avoid a lot of branch/conditional logic. All the conditional logic is handled in M4.

 

How will the the script generated code be partitioned between the memory banks?

 

Manually. The M4 macros are not really any different than using the built-in macro capabilities of the assembler, I just (a) don't know dasm-specific syntax well enough or (b) perhaps it isn't capable of doing the level of complexity I need; I don't know which, in either case, M4 works fine for the task.

 

I hope they do succeed, but I don't see the original timing as realistic.

 

Here's to hoping that we meet the schedule ... knock on wood... So far, so good, although some of the "would be nice" features have been already completed and some of the critical features have slipped. It is a living entity and the real world does trump it unfortunately.

 

No wonder, iirc they stated they're using Perl AND M4. I'd have gone mad long time ago if I tried that

 

M4 is doing code generation... it's no worse than any assembler's macro package, really. I think I posted some code snippets showing it before?

 

Perl is just doing conversion of scripts, maps, and artwork (PNG to raw bitmaps), freeing me up from hand-converting all of that. In particular, I'm not storing text as ASCII -- in order to look up font glyphs more easily I have them in strange order ("0123456789abcdef" at the beginning to make printing numbers in decimal for display easier, and in hex for debugging), some characters are double-width (e.g. "m") and are stored as two parts ("m-left/m-right"), and some glyphs are re-used ("o" and "0" use the same glyph, so there's "no o" in the font, e.g.) to save font space

 

It's all to reduce human labour ... I'd really hate to do the macro unroll by hand but I'd absolutely dread how error-prone it would be to code all the text manually.

 

Sorry to have been so silent on the boards here. The code is running, but there are lines still "over" (too many cycles expended) in the main map kernel. That causes line skips and would on a real TV probably cause rolling. It sure pisses Stella off. I may have to drop one of the colour transitions I was hoping to keep.

 

Stella doesn't seem to like 64kiB binaries. I'm testing as though it were 32kiB, but will need to work around that once the real game data starts going in.

 

At last report from Mayday most of maps were done and some of the artwork for the maps. The test engine is just displaying "static" type patterns right now.

 

By M2 hope to have the display stabilized. If nothing else I may drop to monochrome for a while and come back to that problem :-(

 

Presently focusing efforts on combat engine.

 

Conversation/script engine is doing OK, but no big surprises there, it's basically a 12 column text routine with a little script interpreter tacked onto it and some only-slightly-strange text encoding (mentioned above).

 

As promised, once the core is stabilized I'll be posting here like a proud papa... It'll be a pre-alpha still but I just want to see a grid on the display at this point.

 

Not sure if we were clear but milestones are code tests not game tests so will not include playable game data as Mayday doesn't want to spoil the storyline with partially-functional/buggy/whatever releases, which I agree... no different than perhaps the nonplayable "kernel tests" most of y'all are used-to, though.

 

Incidentally, anyone recommend an EPROM burner that's easy to work with on Linux (Intel or PowerPC) systems? I know nothing about such things but it's beginning to look like that's going to be a necessity to test the full 64kiB tape once we get up to the alpha stage.

 

Silly/minor point of pride, ... no sprite flicker. Dunno if that's good or bad, as it does mean I'm using playfield registers for most of the artwork.

 

Regards to (Paul? Someone?) mentioning the tiny RAM as an issue with RPG: yes... we're mostly using bit-wide flags for stuff. I think the "player RAM" area is like 20 bytes? (still subject to change a bit) I do "steal" some MemCard memory (in theory -- the driver code is still a no-op) to store info only useful when using the MemCard (e.g. player's save game "file" name), and have a "big" chunk of memory that's remapped depending on which mode the tape is in (combat, script/conversation, travel/map, or some of the minor modes like teaser, MemCard/AVox access, &c.).

 

As for the insane degree of hubris to tackle this, well, the list of "nifty things I should have done but it's too late to tack on, now" is growing. The H*R-RPG-demo in particular impressed me with the "smooth" scrolling of the world where we jump by screens; the newer MMUs like 4a50 and so forth, RAM/flash on cart, ...

 

'Nuff said for now, just wanted to touch base lest anyone fear the project was slipping or shelved or so on.

[Godzilla]

huzzah! cant wait to cie whats next :-)

[+SpiceWare]

Perl is just doing conversion of scripts, maps, and artwork (PNG to raw bitmaps), freeing me up from hand-converting all of that.

Care to share?!? I wouldn't be able to use it as is - but it would give me some insight on automating the conversion of Nathan's artwork for the Dragon in Medieval Mayhem.

[+batari]

Stella doesn't seem to like 64kiB binaries. I'm testing as though it were 32kiB, but will need to work around that once the real game data starts going in.

I think the only 64k format that Stella handles is Megaboy bankswitching. It would be fairly easy to update Stella to do EF, if that's what you are using.

'Nuff said for now, just wanted to touch base lest anyone fear the project was slipping or shelved or so on.

Any chance for a demo, even a bad one?

[brpocock]

Perl is just doing conversion of scripts, maps, and artwork (PNG to raw bitmaps), freeing me up from hand-converting all of that.

Care to share?!? I wouldn't be able to use it as is - but it would give me some insight on automating the conversion of Nathan's artwork for the Dragon in Medieval Mayhem.

 

OK, here we go. BIG post :-)

 

Here's the HTML manuals for asm2pod, mkart, mkconverse, mkfont1, and mkmap: tools.manuals.html.zip

 

The Perl scripts, plus "wrap" that I use to capture build output: tools.zip

 

General infos:

• asm2pod extracts Perl-style POD documentation from .s files, so you can use POD inside of assembler comments to generate text, HTML, LaTeX, and PDF documentation.
  
• mkart converts certain PNG black-and-white artworks into data for CiE or other games.
  
• mkconverse compiles Ursa scripts into a symbolic form that the assembler likes, including transcoding the text strings. This is probably only useful for CiE. Not all opcodes are supported yet.
  
• mkfont1 creates the "pre-rotated" form of a font.
  
• mkmap compiles CiE-type map data. Probably only useful for CiE. Some of the limitations of the mapping format and such may be inaccurate in the manual... I keep changing stuff around faster than I can keep track of some days
  
• wrap is just a little command to simultaneously echo output to a log file and the terminal so I can review the output of a "make" later more easily. It laos prints pretty little rows of hyphens and stars so I can tell where one command begins and ends. I once had a CBM assembler that did that ... ah, nostalgia.
  

All of these are subject to ongoing mutilation, but they are functional now. Sample Makefile rules:

 

gen/font1.s:	include/font.s
	tools/mkfont1 $< > $@

gen/%.png:	  art/%.v.png
	convert $< -flip $@

gen/%.s:		art/%.png
	tools/mkart $< > $@

gen/%.s:		game/%.con
	tools/mkconverse $< > $@

gen/%.s:		game/%.map
	tools/mkmap $< > $@

 

I'm using gen as the "generated files" folder (so I can blow away gen/* in make clean. In particular note how I have gen/image.s from art/image.png, and then do an include "gen/image.s" from the appropriate memory bank(s) to pull in the data. The object file then needs to depend on the gen/image.s file to trigger an automatic build.

 

Likewise, the map and conversation/script files need to have dependencies and includes set up for them.

 

I think I broke the MENU code in mkconverse today too, am toying with changing to allow variable-length screens rather than fixed four lines displays, but that feature may be dropped.

 

Mac kids may need/want to grab some Mac ports via e.g. (?)Frisk(?) kit (I forget the name... I run Linux on my Macs...) ... MicroSoft users will need CygWin.

 

Quick PS:

 

The order of characters in the mkconverse manual is braindead-wrong. The correct order should be:

0 2 4 6 8 10
1 3 5 7 9 11

 

Also, the documentation indicates to "see below" regarding lines storage. I forgot to write that section. In brief:

 

Lines are referenced in a "string table" of 12-byte lines. If the same line occurs twice, it's stored once. So, for example, given the two texts:

TALK
MY NAME IS
GEORGE.
HOW ARE
YOU?

TALK
MY NAME IS
SUSAN.
HOW ARE
YOU?

 

The lines table might contain (in twisted notation):

GEORGE
HOW ARE
MY NAME IS
SUSAN
YOU?

 

PPS. I also just noticed some profanity in the output source code. O:) oops.

Edited April 25, 2006 by brpocock

[brpocock]

Any chance for a demo, even a bad one?

 

ASAP

[+SpiceWare]

That was fast, thanks!

[Bruce Tomlin]

Incidentally, anyone recommend an EPROM burner that's easy to work with on Linux (Intel or PowerPC) systems? I know nothing about such things but it's beginning to look like that's going to be a necessity to test the full 64kiB tape once we get up to the alpha stage.

One that I know for sure will work is the BP Microsystems EP-1, which uses a serial interface (up to 38400 baud, and takes XMODEM uploads), so all you need is a serial port and a terminal program. The downside is it's only a 28-pin burner, so 64K is the max chip size you can burn. About the only other thing is that you will probably need to burn a new EPROM to update the burner software (V2.05 is apparently the final version), but the download is available from BP microsystems if you register on their site, or I can put a copy where you can download it.

 

There's one on ebay right now with 25 hours left and an $8.49 minimum bid.

[brpocock]

There's one on ebay right now with 25 hours left and an $8.49 minimum bid.

Thanks! Perfect answer. Cheap and known-to-work is a good combination. I'll just have to re-invest when we start working on the 128kiB sequel... (kidding!)

[Bruce Tomlin]

Even if you don't win that one, usually there's at least one a month. I've programmed an EPROM with a EP-1, OS X, and ZTerm, so I know it works. But haven't used the EP-1 in a while because it's easier to use a burner on the PC in the living room (which I mostly use for playing videos).

[brpocock]

OK, smacking the shit outta Comcast, as I can't fulfil one promise... "the very minute" I had a stable display to upload the test kernel ... well, expect a lovely "spike24.bin" file as soon as I sneakernet one to the office, as Comcast has f---ed up my home Internet connection. (It came with the house. My solid-as-a-rock friends at Speakeasy should be installing in about a week.) However, there's a screenshot on my blog here from before the connection went down (sometime Saturday afternoon), sent very, very late Friday night. That was actually from spikeprecom.bin but I'm switching to something more like a "24-line kernel." The display just looks too scrunched, even with half a row hanging off the top of the TV.

 

No, it's far from perfect, but it does still contain some no-op time in each row, it's not 24kiB long (one test kernel was... it unrolled a bit too much), and in fact, I think it lets me re-introduce some colour change codes that I was afraid I'd have to give up.

 

So: it does exist and it will be uploaded, but requires me to unpack a CD burner or floppy drive or something.

 

The switch from 18 to 24 lines, by the way, does effectively reduce the "pixels per tile" size from 4x9 to 4x8, but it lets me average out the "cycles per line" damages over three lines.

 

(PS. I await barrage of flamage for no binary, but plead y'all hold off a day or two for my upload and then flame me for how lame the test kernel is, instead.)

 

(PPS. My EPROM burner -- thanks Bruce Tomlin -- arrived Saturday also. My blank carts are in transit from Albert. So, I'll soon test on hardware, but not yet.)

Edited May 8, 2006 by brpocock

[Shawn]

Great news!! Can't wait to try it out. I am still a hardcore supporter. From Start to finsish I'm on board with the one!! RPG on the 2600 :drool:

[Bruce Tomlin]

So: it does exist and it will be uploaded, but requires me to unpack a CD burner or floppy drive or something.

Is that the homebrewer's equivalent of the "I just found this cool proto but I don't have a camera" guys we've been having lately? :-)

[+Nathan Strum]

I just found this cool digital camera... but I don't have any prototypes to take pictures of.

[brpocock]

Is that the homebrewer's equivalent of the "I just found this cool proto but I don't have a camera" guys we've been having lately? :-)

 

Yeah, 'fraid so. The really stupid part? I forgot my Cube has a CD-R drive in it, I was looking for my Firewire one as I unpack... then happened to notice the mount path on the Cube was /media/cdrecorder.

 

So, superb stupidity on my part.

 

DISCLAIMER: This is just a test kernel. It's not a playable demo or anything yet! But the hard part is done: the kernel timings are worked out for the row-by-row drawing. Not that this will stop the flamage, but hey, constructive(?) flames encouraged.

 

3li resolution for playfield bitmaps and 2li resolution for P0/P1, multiplying out to nice 24li per row of tiles, which makes the 8x8 grid fill the display pretty nicely. Only P0 has line-specific (2li specific anyways) positioning though.

 

I'll dump s'more details on my blog page and screenshots later if we've a slow day 't the office.

 

PS. Don't blame Mayday for the art either. This is total programmer placeholder art.

 

EDIT: DAMMIT. Here's the attachment. tiledraw.bin

Edited May 10, 2006 by brpocock

[ScottHuggins]

This is pretty impressive. Wait, there's nothing here. I read 8 pages of nothing.

[Shawn]

This is pretty impressive. Wait, there's nothing here. I read 8 pages of nothing.

 

 

I cant see any attachments either and I want to try this early build.

[brpocock]

Wait, there's nothing here

I cant see any attachments either and I want to try this early build.

Sorry... it seems to be firmly attached now: tiledraw.bin

For your viewing pleasure:

[vdub_bobby]

Well, a month and a half late...

 

 

That's about the way things go, so you're not too far off a realistic schedule. Keep working away!