Jump to content

Search the Community

Showing results for tags 'as1600'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Atari Systems
    • Atari General
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Atari VCS
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Classic Consoles
  • Classic Computing
  • Modern Consoles
  • Gaming General
  • Marketplace
  • Community
  • Community
  • Game Programming
  • Site
  • PC Gaming
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions
  • Robin Gravel's new blog's My blog
  • Robin Gravel's new blog's Games released
  • Atari Video Club's Harmony Games
  • Atari Video Club's The Atari Gamer
  • Atari Video Club's Video Game Summit
  • Atari Video Club's Discsuuions
  • Star Wars - The Original Trilogy's Star Wars Talk
  • PlusCart User's Bug reports
  • PlusCart User's Discussion
  • DMGD Club's Incoming!
  • DASM's General
  • AtariVox's Topics
  • Gran Turismo's Gran Turismo
  • Gran Turismo's Misc.
  • Gran Turismo's Announcements
  • The Food Club's Food
  • The Food Club's Drinks
  • The Food Club's Read me first!
  • The (Not So) Official Arcade Archives Club's Rules (READ FIRST)
  • The (Not So) Official Arcade Archives Club's Feedback
  • The (Not So) Official Arcade Archives Club's Rumor Mill
  • The (Not So) Official Arcade Archives Club's Coming Soon
  • The (Not So) Official Arcade Archives Club's General Talk
  • The (Not So) Official Arcade Archives Club's High Score Arena
  • Adelaide South Australia Atari Chat's General Chat & Welcome
  • Adelaide South Australia Atari Chat's Meets
  • Adelaide South Australia Atari Chat's Trades & Swaps
  • KC-ACE Reboot's KC-ACE Reboot Forum
  • The Official Lost Gaming Club's Lost Gaming
  • The Official Lost Gaming Club's Undumped Games
  • The Official Lost Gaming Club's Tip Of My Tounge
  • The Official Lost Gaming Club's Lost Gaming Vault
  • The Official Lost Gaming Club's Club Info
  • GIMP Users's Discussion
  • The Homebrew Discussion's Topics


There are no results to display.

There are no results to display.


  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start










Custom Status



Currently Playing

Playing Next

Found 7 results

  1. Another recent thread from INTVPROG that's getting cock-blocked by Yahoo's crappiness. ___________________________ Hi, there, I just noticed a change in the assembler's formatting of the LISTING file. Whereas each decle was always rendered in its own line, now consecutive decles (like for strings) are arranged on the same line. What's more, these lines appear to be of arbitrary length, making it harder (at least for me) to discern specific words. For instance, contrast the following original formatting: ; I can follow this vertical stream of words... 500F 0001 DECLE 1,1,1,1,1 ; 500F Initial color stack 0 and 1: Blue 5010 0001 5011 0001 5012 0001 5013 0001 5014 0075 DECLE 2017 - 1900 ; $5014 5015 0043 STRING "Christmas Carol", 0 5016 0068 5017 0072 5018 0069 5019 0073 501A 0074 501B 006D 501C 0061 501D 0073 501E 0020 501F 0043 5020 0061 5021 0072 5022 006F 5023 006C 5024 0000 With the new formatting: ; Looks like a jumble of numbers thrown in a pack... 500F 0001 0001 0001 0001 DECLE 1,1,1,1,1 ; 500F Initial color stack 0 and 1: Blue 5013 0001 5014 0075 DECLE 2017 - 1900 ; $5014 5015 0043 0068 0072 0069 STRING "Christmas Carol", 0 5019 0073 0074 006D 0061 0073 0020 0043 0061 5021 0072 006F 006C 0000 Line at location 0x5019 seem to pass beyond its "margin," blending into the source. I find this highly distracting. Is there a way to regain the previous formatting, an assembler directive or option perhaps? dZ.
  2. I just uploaded jzintv-20180509 to the webserver. This is primarily a bugfix release, motivated by a semi-serious bug that crept into AS1600 back in December. In this release: BUGFIX: AS1600: Fix right shifts of negative values. This was a pants-on-head stupid bug. BUGFIX: jzintv, dasm1600: Display JR R5 instead of MOVR R5, R7 in disassembly. It was always intended to. Bug caught by upgrade to GCC 8.1. Compile fix: Change 'macosx' to 'PLAT_MACOS' to allow building on MacOS X 10.13 and later. Typo in as1600 docs: __FEATURE.LISTCOL, not __FEATURE.ROTATE Minor improvement: Improve dis1600's handling of an opcode that may, or may not be, an SDBD. Misc: Upgraded to GCC 8.1 on Linux and MacOS X. Get it at the usual spot: http://spatula-city.org/~im14u2c/intv/
  3. OK, I've made a raft of improvements since last week's release. All this is now available in the 2018-01-08 release. NEW: Add _EXPMAC keyword, to force macros to expand in both the taken and not-taken branches of an IF. This is needed for IF-statements inside a RPT block, whose taken/not-taken behavior varies across loop iterations. NEW: Increase resolution of release_date to include hours, minutes, seconds, and timezone. NEW: Add build_date and version CFGVARs. build_date takes the same format as release_date. version is an arbitrary format string. Both tags can appear an arbitrary number of times. NEW: Add %z specifier to TODAY_xxx. Reports timezone as +HHMM in TODAY_STR_xxx. Reports timezone as minutes relative to UTC in TODAY_VAL_xxx. NEW: Add _ROTL16, _ROTL32, _ROTR16, _ROTR32 operators.Same precedence as SHL, SHR, SHRU. Internal: Increase IF-ELSE-ENDI stack depth from 32 to 256. Internal: Additional infrastructure for normalizing metadata between different object file types. BUGFIX: Add missing __FEATURE.TODAY for the TODAY_xxx feature. This was supposed to be in the last release, but a fatfingered edit fail deleted it. BUGFIX: Fix some nested RPT cases. Multiple RPTs inside a nested RPT now work. RPT guarded by an IF also now works. BUGFIX: Fix some metadata tag behavior when loading ROMs w/ tags. Misc: Start marking stuff 2018. Misc: Update documentation for new features.
  4. I am re-listening to Intellivisionaries Episode 4, featuring Christmas Carol. James was talking about the bug he experienced at CGE. It got me thinking "what if there is a production bug in the next thing I make, how can I get some information about it?" So... Would it be possible for a running game to somehow catch a crash/Exception and write the ROM/RAM/STIC contents to a JLP "save slot"? I was thinking that if all of that was collected into a file that could be read later, it would be A Good Thing . I don't know if that means running the game within a kind of "container" or if there is some kind of hook that can be added to in the as1600 build process, or what. I think a JLP board would have enough storage to hold the largest Inty games several times over, definitely enough to store the entire state of a crashed environment. If the crash happens in emulation, the file could be parsed by some tooling, if it happens on a cart, I'm not sure how to physically get the data out... What do you think?
  5. All, I've made a minor but useful update to AS1600 in this release. jzIntv should be unchanged, other than to be freshly compiled. Download the update here: http://spatula-city.org/~im14u2c/intv/ Updates: The -m (aka --show-map) flag now works again. This will print a memory map summary for your program at the end of assembly. The new -e flag (aka. --err-if-overwritten) flag now enables ROM overwrite checks. (More below.) The new directives ERR_IF_OVERWRITTEN and FORCE_OVERWRITE now provide the ability to warn about overwriting already-assembled ROM, with the ability to override the warning. What is ROM overwrite? First, the tl;dr: The most common symptom is that your program has started crashing and you don't know why. Add the '-e' flag to your assemble script, and this will become an assemble time error than a run time error. Longer explanation: Consider the following simple example: . ORG $5000 DECLE 1, 2, 3, 4, 5, 6, 7, 8 ORG $5004 DECLE 8, 7, 6, 5, 4, 3, 2, 1 . This code assembles 8 words at $5000 - $5007, and then assembles 8 more words at $5004 - $500B. The second part overwrites the ROM assembled at $5004 - $500F. AS1600 currently does not warn about this. Usually, when this happens, it is an error, but occasionally it's a feature. For example, I'll often assemble a fixed pattern into memory, and then assemble my game over top of that, so I have a consistent fill value for the portions of ROM I'm not using yet. The latest release of AS1600 adds directives to control this behavior. I'll just paste the documentation from jzintv/doc/utilities/as1600.txt here: . ------------------------------------------------------------------------------ ERR_IF_OVERWRITTEN expr Mark code as "not intended to be overwritten" FORCE_OVERWRITE expr Force code to be overwritten anyway ------------------------------------------------------------------------------ By default, AS1600 lets you assemble new code over addresses you've already assembled code into. That allows for some interesting tricks; however, most often this is really an error. The ERR_IF_OVERWRITTEN directive controls a flag that indicates whether the code that follows may be safely overwritten. 0 means "safe to overwrite", while 1 means "throw an error if overwritten." >>> Note: ERR_IF_OVERWRITTEN defaults to 0. You can change the default at >> the command line by adding the flag -e or --err-if-overwritten For example, if I wanted to fill some ROM with a fixed pattern, and then overwrite it with final code, I could do something like this: ERR_IF_OVERWRITTEN 0 ; About to write some filler data ORG $6000 REPEAT 4096 / 8 DECLE -1, -1, -1, -1, -1, -1, -1, -1 ENDR ERR_IF_OVERWRITTEN 1 ; Now overwrite it with real code ORG $6000 ; The following generates no errors or warnings. fun: PROC MVII #ISR, R0 MVO R0, $100 SWAP R0 MVO R0, $101 ;... ENDP ; This code, however, will trigger an error, because it's overwriting ; the code we just assembled at 'fun': ORG $6000 DECLE 12, 34 ; ERROR - ROM overwrite error on $6000 - $6001 The FORCE_OVERWRITE directive gives you the ability to forcibly overwrite code that was previously assembled with ERR_IF_OVERWRITTEN == 1. Revisiting the previous example: ERR_IF_OVERWRITTEN 1 ; Now overwrite it with real code ORG $6000 fun: PROC MVII #ISR, R0 MVO R0, $100 SWAP R0 MVO R0, $101 ;... ENDP ; With FORCE_OVERWRITE, this code now assembles without errors. FORCE_OVERWRITE 1 ORG $6000 DECLE 12, 34 The FORCE_OVERWRITE directive is meant for use in specialized macros that may wish to "back-patch" code that otherwise should have ERR_IF_OVERWRITTEN turned on. Use it sparingly. There is no way to query the current state of ERR_IF_OVERWRITTEN or FORCE_OVERWRITE. If you need to track that for some reason, wrap these in macros. Truth table: ERR_IF_OVERWRITTEN FORCE_OVERWRITE Result on an overwrite off off No error off ON No error ON off Report an error ON ON No error Note that ERR_IF_OVERWRITTEN tags current code to detect _future_ attempts to overwrite, while FORCE_OVERWRITE affects the code you're assembling right now. For example, this still generates an error, because the first DECLE was assembled with ERR_IF_OVERWRITTEN == 1: ERR_IF_OVERWRITTEN 1 ORG $6000 DECLE 1234 ERR_IF_OVERWRITTEN 0 ORG $6000 DECLE 3456 Conversely, this example does _not_ generate an error: ERR_IF_OVERWRITTEN 0 ORG $6000 DECLE 1234 ERR_IF_OVERWRITTEN 1 ORG $6000 DECLE 3456
  6. 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/
  7. Hi there, Does anyone have any good information on the exact structure of the expected ROM header in an Intellivision ROM? I've found examples that strategically pass zeros and ones (like the ones in the jzintv documentation labeled "EXEC friendly ROM header") but I would really like to know if possible more about what exactly is supposed to be here and why. Does anyone here have any leads or know where I might be able to find this sort of documentation? Any help would be appreciated. Thanks a bunch!
  • Create New...