Jump to content
intvnut

Final jzIntv / SDK-1600 update for 2017

Recommended Posts

Happy holidays, y'all!

 

I've put together a nice jzIntv / SDK-1600 update to round out the year with.

 

Updates in this release:

 

  • Lots of documentation updates for existing and new AS1600 features in ./doc/utilities/as1600.txt
    • Improved documentation on expression list support
    • Improved documentation on CFGVAR support, including tables describing the supported metadata variables and their meaning.
    • NEW: TODAY_STR_xxx and TODAY_VAL_xxx functions that return the current date and time
    • NEW: Expression-list slicing and indexing
  • Updates to cart.mac
    • NEW: Better documentation regarding static vs. dynamic-paged ROM segments
    • NEW: Explicitly mark which segments are static vs. dynamic, and adapt ROMSEGSZ to select among static segments.
    • NEW: Add CURROMSEG and CURROMPAG symbols to query the current ROM segment number and, for dynamic-paged segments, what Mattel page number it's using.
    • Switch to DZ-Jay's ECS detection algorithm
  • Updates to AS1600:
    • NEW: Add a -v flag to report assembler version (SVN revision number)
    • NEW: Add long-option spellings for flags
    • NEW: Add --help (aka. -h or -?) usage information
    • NEW: TODAY_STR_xxx / TODAY_VAL_xxx support (mentioned above)
    • Bugfixes to expression-list handling
  • Updates to jzIntv:
    • NEW: Reports SVN revision number
    • Randomize JLP memory and Intellicart memory when given --rand-mem
    • Document flags which control border area in --help output
    • Rename tutorvision_compat to tv_compat, as it was already tv_compat most places in the source.
    • Minor cleanups suggested by various sanitizers and warnings from different compiler environments. (Trying to keep it clean for -Werror.)

 

Also, the Windows build is now built with GCC 7.2.0 rather than GCC 6.3.0. Not sure that makes a huge difference.

 

Go check it out: http://spatula-city.org/~im14u2c/intv/

  • Like 5

Share this post


Link to post
Share on other sites

Wow! Fantastic! That's like the best "Last Hurrah" update, and just at the nick of time too! :)

 

Thanks for all the work put into keeping the tools current. Many of those changes have been long desired, and the rest will surely be useful.

 

Have and prosperous Happy New Year!

 

-dZ.

Share this post


Link to post
Share on other sites

Here's one cute thing I recommend everyone put in their code while they're in the development phase:

.

  CFGVAR "release_date" = TODAY_STR_LOC("%Y-%m-%d")

.

Or, if you're using IntyBASIC and have the latest AS1600:

.

   ASM CFGVAR "release_date" = TODAY_STR_LOC("%Y-%m-%d")

.

This will capture the date you assembled a ROM as metadata with the ROM. That'll hopefully make it easier to keep track of random binary images laying around while you're developing.

 

It's not foolproof, mind you—it only captures when you ran the assembler, and it doesn't tell you if you've assembled an older version vs. a newer version. But, it's something.

 

BTW, the latest versions of AS1600 and jzIntv will track this release date tag both with BIN+CFG format and ROM format. For ROM format, use the new "rom_metadata" tool to reveal the date. Otherwise, look in the CFG file. Example:

.

$ cat example.bas

        ASM CFGVAR "release_date" = TODAY_STR_LOC("%Y-%m-%d")
here:   goto here

$ ./intybasic example.bas example.asm

IntyBASIC compiler v1.2.9 Nov/07/2017
(c) 2014-2016 Oscar Toledo G. http://nanochess.org/

0 used 8-bit variables of 228 available
0 used 16-bit variables of 47 available
Compilation finished

$ as1600 -o example example.asm       # this step outputs both BIN+CFG and ROM

 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

$ cat example.cfg
 
[mapping]
$0000 - $01D9 = $5000

[vars]
release_date = "2017-12-31"

$ rom_metadata example.rom 

>> ---------------------------------------------------- >>
    Date                 : 2017-12-31
<< ---------------------------------------------------- <<
Processed 1088 of 1088 bytes

  • Like 4

Share this post


Link to post
Share on other sites

 

Here's one cute thing I recommend everyone put in their code while they're in the development phase:

.

  CFGVAR "release_date" = TODAY_STR_LOC("%Y-%m-%d")

.

Or, if you're using IntyBASIC and have the latest AS1600:

.

   ASM CFGVAR "release_date" = TODAY_STR_LOC("%Y-%m-%d")

.

This will capture the date you assembled a ROM as metadata with the ROM. That'll hopefully make it easier to keep track of random binary images laying around while you're developing.

 

It's not foolproof, mind you—it only captures when you ran the assembler, and it doesn't tell you if you've assembled an older version vs. a newer version. But, it's something.

 

BTW, the latest versions of AS1600 and jzIntv will track this release date tag both with BIN+CFG format and ROM format. For ROM format, use the new "rom_metadata" tool to reveal the date. Otherwise, look in the CFG file. Example:

.

$ cat example.bas

        ASM CFGVAR "release_date" = TODAY_STR_LOC("%Y-%m-%d")
here:   goto here

$ ./intybasic example.bas example.asm

IntyBASIC compiler v1.2.9 Nov/07/2017
(c) 2014-2016 Oscar Toledo G. http://nanochess.org/

0 used 8-bit variables of 228 available
0 used 16-bit variables of 47 available
Compilation finished

$ as1600 -o example example.asm       # this step outputs both BIN+CFG and ROM

 ERROR SUMMARY - ERRORS DETECTED 0
               -  WARNINGS       0

$ cat example.cfg
 
[mapping]
$0000 - $01D9 = $5000

[vars]
release_date = "2017-12-31"

$ rom_metadata example.rom 

>> ---------------------------------------------------- >>
    Date                 : 2017-12-31
<< ---------------------------------------------------- <<
Processed 1088 of 1088 bytes

 

Hmmm... I think it may be more useful to have IntyBASIC produce a "build" number as meta-data, and the release date should be reserved for actual releases.

 

When you have, say, a long gestation period with beta-testing and such, you end up with lots of binaries. It would be very useful to be able to tell the binaries apart by build or version number. However, it would be sort of confusing to have them all have different "release dates" when only the final one (or subsequent patched versions) were actually released.

 

I am a Data Architect by profession, so I hate overloaded and non-atomic data elements. ;)

 

-dZ.

  • Like 1

Share this post


Link to post
Share on other sites

The reason I didn't suggest "build_date" or "build_number" tag is that we lacked the foresight to define a "build_date" or "build_number" tag back in 2001 when we first defined the tag format, and I continued that lack of foresight when I recently revived and revised it. :-) (By "we", I mean myself, Kyle Davis, and other denizens of INTVPROG around that time.)

 

If you add a build_number or build_date tag, it'll get dropped if you convert to .ROM format. While there is a provision in the spec for additional arbitrary tags, I haven't implemented it yet.

 

I'd love to be able to integrate w/ a revision control system (SVN, Hg, git, Perforce, etc) and extract revision information that way, so it could be piped through. I don't think that's doable for AS1600 without incurring significant external dependencies.

 

CSB time:

 

At my previous job, we had all sorts of weird issues w/ folks running out of date versions of code, and then reporting data as new, when really it was stale and flawed. I invested significant effort building version reporting into all the stages of the flow, so that we could catch these lapses. e.g. report the versioning information for all the components involved, so you could ensure that the data you're evaluating is what you think it is. We had some self-inflicted wounds with our own home-grown revision control system. It was slow, creaky, prone to bizarre failures (for example, it'd core dump if you had an apostrophe in the commit message), used symlinks to read-only copies of files (requiring exclusive checkouts if you wanted to modify a file), and therefore encouraged really awful practices to work around it and still be productive. Folks would move symlinks out of the way and make their own local mutable copies of files, etc...

 

So I built a ton of paranoia into my infrastructure to detect and record all these things, so if someone reported new performance data, for example, we could determine if they ran what they thought they ran.

 

It really is a similar problem to knowing what version you're testing while testing a homebrew game, I suppose, only I imagine most homebrews aren't quite that chaotic.

Edited by intvnut
  • Like 1

Share this post


Link to post
Share on other sites

The reason I didn't suggest "build_date" or "build_number" tag is that we lacked the foresight to define a "build_date" or "build_number" tag back in 2001 when we first defined the tag format, and I continued that lack of foresight when I recently revived and revised it. :-) (By "we", I mean myself, Kyle Davis, and other denizens of INTVPROG around that time.)

 

If you add a build_number or build_date tag, it'll get dropped if you convert to .ROM format. While there is a provision in the spec for additional arbitrary tags, I haven't implemented it yet.

 

I'd love to be able to integrate w/ a revision control system (SVN, Hg, git, Perforce, etc) and extract revision information that way, so it could be piped through. I don't think that's doable for AS1600 without incurring significant external dependencies.

 

CSB time:

 

At my previous job, we had all sorts of weird issues w/ folks running out of date versions of code, and then reporting data as new, when really it was stale and flawed. I invested significant effort building version reporting into all the stages of the flow, so that we could catch these lapses. e.g. report the versioning information for all the components involved, so you could ensure that the data you're evaluating is what you think it is. We had some self-inflicted wounds with our own home-grown revision control system. It was slow, creaky, prone to bizarre failures (for example, it'd core dump if you had an apostrophe in the commit message), used symlinks to read-only copies of files (requiring exclusive checkouts if you wanted to modify a file), and therefore encouraged really awful practices to work around it and still be productive. Folks would move symlinks out of the way and make their own local mutable copies of files, etc...

 

So I built a ton of paranoia into my infrastructure to detect and record all these things, so if someone reported new performance data, for example, we could determine if they ran what they thought they ran.

 

It really is a similar problem to knowing what version you're testing while testing a homebrew game, I suppose, only I imagine most homebrews aren't quite that chaotic.

 

I don't think most of that is necessary except in the most extreme cases. I remember at least one situation during Christmas Carol's long beta-testing period where I put out the wrong binary and we were going crazy trying to figure out how and why it was possible for everyone but me to see a bug I had already fixed. (I believe you were in at least one of those times.)

 

For such extreme cases, it would be useful to have some watermark or means to identify unambiguously which build it was. However, it is such a rare occurrence, that it is not worth the trouble implementing a complex solution for it. Especially, when you consider that the hardest problem to solve during those situations is realizing and acknowledging that you are in it -- comparing and verifying the build can be done with current tools, albeit not as elegantly as with a specialized solution. The point is that, in all those times it happened to me, the moment I realized I had the wrong build was the moment we solved it: even just a re-build and release without further analysis will fix it by providing a clean version.

 

Anyway, integration with SVN is appealing but perhaps not worth much pain. Adding support for a manual "build number" or "build date" (I prefer the former, but either or both will do), is probably good enough, and perhaps easier to implement in as1600. Integrating that with SVN and GIT can be left to enterprising authors, most of which make their own build scripts anyway. :)

 

My only gripe is the overloading of the meaning of "release date," which I hope everybody uses consistently across our community to mean the actual release date of the game. This can then be consistent with the classic titles in a well organized library.

 

Anyhoo, something to think about through 2018. :)

Share this post


Link to post
Share on other sites

During Space Patrol, I added a date string to the executable fairly early, because I wasn't using revision control (yet), and it was getting hard to keep track of versions. But, manually updating it was annoying, and I sometimes forgot.

 

During one other homebrew I was involved with, we had similar issues w/ keeping track of which binaries were which. That one got solved with automation (scripts outside the assembler).

 

I imagine many folks aren't using revision control for their projects, and the ones that are are savvy enough to build the necessary scripts if they want them. I was more just openly musing.

Share this post


Link to post
Share on other sites

During Space Patrol, I added a date string to the executable fairly early, because I wasn't using revision control (yet), and it was getting hard to keep track of versions. But, manually updating it was annoying, and I sometimes forgot.

 

During one other homebrew I was involved with, we had similar issues w/ keeping track of which binaries were which. That one got solved with automation (scripts outside the assembler).

 

I imagine many folks aren't using revision control for their projects, and the ones that are are savvy enough to build the necessary scripts if they want them. I was more just openly musing.

Another question for you...why are the image, avi's and mvi's not named with the rom name:

MySuckyGame.Rom / bin/cue
--MySuckyGame_shot0103.gif
--MySuckyGame_avi_0003.avi
--MySuckyGame_mvi_0002.imv

and why does shot not have an underscore after it? ;)

  • Like 2

Share this post


Link to post
Share on other sites

Another question for you...why are the image, avi's and mvi's not named with the rom name:

MySuckyGame.Rom / bin/cue
--MySuckyGame_shot0103.gif
--MySuckyGame_avi_0003.avi
--MySuckyGame_mvi_0002.imv

and why does shot not have an underscore after it? ;)

 

As I mentioned elsewhere, jzIntv does not have very coherent handling of files. As for the shotXXXX.gif, avi_XXXX.avi, mvi_XXXX.imv, notice anything about the names? They're all 8.3, like good ol' DOS.

 

jzIntv started off life with a DOS build that ran under DJGPP + GO32.EXE way back in the Win95 era. That's also why 320x200 (VGA Mode 13h), etc... The screenshot feature is one of the oldest features, although it originally wrote PPM files rather than GIF.

  • Like 1

Share this post


Link to post
Share on other sites

I still do manual backups of each of my games at each "milestone", just because I don't like to put them in the "cloud", anyway is known that even there can be lost.

 

Most recently I've made this small bash script to get a build counter each time I'm doing a compilation (this inside a c.sh file):

count=$(cat counter.txt)
((count++))
echo > counter.txt $count
echo > build.bas PRINT \"$count\"
./intybasic --title "Cute little game" $1.bas $1.asm
./as1600 -o $1 -l $1.lst -j $1.smap $1.asm
./jzintv -z1 $1.rom

Then inside the IntyBASIC program in the title screen I simply add this to show the build number:

        INCLUDE "build.bas"

Not perfect, but it helps a lot.

Share this post


Link to post
Share on other sites

I still do manual backups of each of my games at each "milestone", just because I don't like to put them in the "cloud", anyway is known that even there can be lost.

 

You know, you can run Mercurial entirely locally to your machine. You don't even need a network connection. Every Mercurial repo has a full history included in it. "hg clone" gives you a new work directory that has a full copy of everything checked into the source repo, along with its history. It makes making "experimental branches" really safe and cheap. You can always pull commits back onto the mainline if the experiment works out.

 

Or, you could even use git. Mercurial and git have similar high level models; however, I find Mercurial to be much more user-friendly. Seriously, go check out Joel Spolsky's occasionally humorous (but always informative) tutorial.

 

On my own stuff, I'm using a SVN server I set up back in 2006. I back up that repo from time to time. Downside of SVN is it requires network access. Upside is that there's a single global version, and it lets me cater access controls the way I'd like. It's fine when there's a few people working on a project. It doesn't scale well to 100s or 1000s. (That's why the Linux kernel uses Git and Linus Torvalds claims SVN is fundamentally broken.)

  • Like 2

Share this post


Link to post
Share on other sites

I still do manual backups of each of my games at each "milestone", just because I don't like to put them in the "cloud", anyway is known that even there can be lost.

 

 

Who needs the cloud? I just use a local SVN client/server, and a regular TimeCapsule backup. :)

 

 

 

 

On my own stuff, I'm using a SVN server I set up back in 2006. I back up that repo from time to time. Downside of SVN is it requires network access. Upside is that there's a single global version, and it lets me cater access controls the way I'd like. It's fine when there's a few people working on a project. It doesn't scale well to 100s or 1000s. (That's why the Linux kernel uses Git and Linus Torvalds claims SVN is fundamentally broken.)

 

 

What is this network access requirement you talk about? Even when I used Windows, my SVN server ran entirely in the same machine. On Windows, I used TortoiseSVN. On Mac, I used the built-in SVN that comes with the operating system and eventually upgraded to Cornerstone, which is a GUI built on top of the tool.

 

Both of these run entirely on a local machine with no network access necessary.

 

-dZ.

  • Like 1

Share this post


Link to post
Share on other sites

 

What is this network access requirement you talk about? Even when I used Windows, my SVN server ran entirely in the same machine. On Windows, I used TortoiseSVN. On Mac, I used the built-in SVN that comes with the operating system and eventually upgraded to Cornerstone, which is a GUI built on top of the tool.

 

Because I use several machines, I have one SVN server that multiple people access from multiple computers. So, if you're using SVN in the usual setup (central server, many clients), it requires network access. That's how I sync my code across Linux (x86-64), Linux (R-Pi), Windows, and Mac. It's also how I share code w/ collaborators.

 

Certain SVN commands require a ping back to the server, such as "svn log" and "svn diff". I love "svn diff", and I miss it heavily if I'm trying to code while on a flight somewhere. For one project, I use "svn update" followed by "svn status" as part of my release build process (basically to ensure I don't have any stale files and to record whether I have un-checked-in changes). That step fails in my setup if there's no network.

 

SVN isn't really set up for multi-repository development. There's some read-only mirror/proxy support (and that'd fix my "svn diff" issue), but that's not really the same thing. For read-write repos, each SVN repo has its own revision number sequence separate of the others, so SVN revision number isn't meaningful between different repos.

 

If you're a single developer on a single machine, setting up SVN locally filesystem-based access for yourself is fine. It just doesn't scale beyond one machine very well.

 

In contrast, Mercurial and Git are inherently multi-repository, and designed from the start to support distributed repos on multiple machines. If you want a central repo that contains the final release build, you can have one, and you can even sync over the network. But, since every repo has a full, self-contained history, you can do all the major commands without network access, regardless of how many machines or developers are collaborating. The only steps that require the network are the ones explicitly pulling or pushing patches to repos on another computer.

Share this post


Link to post
Share on other sites

 

Because I use several machines, I have one SVN server that multiple people access from multiple computers. So, if you're using SVN in the usual setup (central server, many clients), it requires network access. That's how I sync my code across Linux (x86-64), Linux (R-Pi), Windows, and Mac. It's also how I share code w/ collaborators.

 

Certain SVN commands require a ping back to the server, such as "svn log" and "svn diff". I love "svn diff", and I miss it heavily if I'm trying to code while on a flight somewhere. For one project, I use "svn update" followed by "svn status" as part of my release build process (basically to ensure I don't have any stale files and to record whether I have un-checked-in changes). That step fails in my setup if there's no network.

 

SVN isn't really set up for multi-repository development. There's some read-only mirror/proxy support (and that'd fix my "svn diff" issue), but that's not really the same thing. For read-write repos, each SVN repo has its own revision number sequence separate of the others, so SVN revision number isn't meaningful between different repos.

 

If you're a single developer on a single machine, setting up SVN locally filesystem-based access for yourself is fine. It just doesn't scale beyond one machine very well.

 

In contrast, Mercurial and Git are inherently multi-repository, and designed from the start to support distributed repos on multiple machines. If you want a central repo that contains the final release build, you can have one, and you can even sync over the network. But, since every repo has a full, self-contained history, you can do all the major commands without network access, regardless of how many machines or developers are collaborating. The only steps that require the network are the ones explicitly pulling or pushing patches to repos on another computer.

 

I understand all that, but I thought we were discussing personal use for programmers here, who currently don't use any source control system at all. That's why I thought it was strange that you mentioned some "requirement" for network access as a downside for SVN. I would imagine that any distributed version control system used in a distributed fashion would require network access.

 

Anyway, I didn't intend to get into some pissing contest on source control's features. I was genuinely trying to suggest that there are easy tools that can be used which are better than just copying files with timestamps on them, and they don't have to be overwrought for simple use-cases.

 

And also, that overloading the meaning of "release date" has bigger implications than perpetuating those copying files with timestamps use-cases.

 

-dZ.

Share this post


Link to post
Share on other sites

And also, that overloading the meaning of "release date" has bigger implications than perpetuating those copying files with timestamps use-cases.

 

You'll be happy to know the next release of jzIntv and SDK-1600 has plumbed through new "build_date" and "version" tags. Overloading release_date bothered me from the start, FWIW. I should have added build_date much earlier. I've also upgraded the date/time tags to support recording the full time, down to seconds and timezone. That way you will be able to say:

.

     CFGVAR "build_date" = TODAY_STR_LOC("%Y-%m-%d %H:%M:%S %Z")

.

The version tag is an arbitrary string. It's up to you to decide what you want to put in there.

 

I hope to have this out this weekend. I found a couple of bugs in the last release of jzIntv / SDK-1600, and so this is mainly a bugfix release, but it will have a couple minor features added.

Edited by intvnut

Share this post


Link to post
Share on other sites

Well, I'm sure glad you edited your post. I was taken aback by the original I received via e-mail notification. :o

 

 


You'll be happy to know the next release of jzIntv and SDK-1600 has plumbed through new "build_date" and "version" tags. Overloading release_date bothered me from the start, FWIW. I should have added build_date much earlier. I've also upgraded the date/time tags to support recording the full time, down to seconds and timezone. That way you will be able to say:
.

     CFGVAR "build_date" = TODAY_STR_LOC("%Y-%m-%d %H:%M:%S %Z")

.
The version tag is an arbitrary string. It's up to you to decide what you want to put in there.

I hope to have this out this weekend. I found a couple of bugs in the last release of jzIntv / SDK-1600, and so this is mainly a bugfix release, but it will have a couple minor features added.

 

Awesome! I haven't had a chance to test the emulator much. I'm still working on adapting my framework to take advantage of the newer features. :)

 

Thanks for all the hard work.

 

-dZ.

Share this post


Link to post
Share on other sites

I'm working on the first release of the new year. It's partly a bugfix release, and partly a feature release. Here's the diffstat... not bad for a week.

 

post-14113-0-49598800-1515388083_thumb.png

Edited by intvnut
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...