IntyBASIC Stack Overflow Check?

[IntyBASIC Stack Overflow Check?]

IIRC, most IntyBASIC generated code only uses the stack to remember return addresses.  If you see a BEGIN statement in the generated code, that's really PSHR R5.  Otherwise, the only stack accesses are from the IntyBASIC support code in the prologue/epilogue files, and the 9 words of stack space the interrupt handler requires.  (Note: This could be reduced to 8 if the BEGIN/RETURN pair in _int_vector were removed, and the interrupt handler simply did B $1014 at the end.)

 

$2F0 - $307 is only 24 words of stack space.  That's not a lot of stack space.  Subtract 9 off the top for interrupts, and probably another 8 or so for the worst case library functions that might get invoked.   What that translates to is that you can't really GOSUB more than about 7 levels deep.  Note: I'm guessing on the 8 for the worst case library function.  It's probably less than that.

 

Different question:  Should the stack overflow check be sensitive to the --jlp or --cc3 flag?  If you use either of those flags, I believe all 16-bit variables go to the extended 16-bit memory.  In that case, you actually have stack space up to $319, and that gives you an extra 17 words.

[Coming Soon From BSR]

On 11/19/2020 at 8:32 AM, JasonlikesINTV said:

It changed to Mind S. Trike.

Shhhhh! That was supposed to be Top S. Ecret!

 

On 11/18/2020 at 6:09 AM, Bamse said:

The LTO carts used for these have on-board ram I think. Maybe that is used? 

JLP boards, but yes. It uses the onboard RAM.

 

Mind S. Trike (now that Jason's let the cat out of the bag) requires other modifications to make it work without ECS. For example, you can't leave the title screen without an ECS keyboard. That, and it has a command line interface rather than a menu.

 

 

[Collision detection issues.]

Why isn't there an if-statement around this?

if onland = 0 then    
    if santay=80 then onland=1 : goto toporbottom
    if santay=17 then onland=1 : goto toporbottom
end if

Granted, you will need to move where you set onland = 0 up slightly.

 

Also: Remember hardware collision detection has a one or two frame delay, depending on your perspective.

1. Frame N-1: compute MOB positions for frame N.
2. Frame N: MOBs are displayed, collisions computed.
3. Frame N+1: game gets to see the collisions for positions it computed in frame N-1.

I don't know if that factors into your issue as well, since you're combining your current notion of X/Y with the collision information from a previous frame.

 

I haven't looked at the .bas file yet. I don't think my phone lets me do that easily.

[Dev Kit with Mainline Computers of the 80s?]

11 hours ago, nanochess said:

 

Although no thing prevents from writing a CP1610 assembler for even older PC like the XT/AT class, for the classic taste it would be amazing if someone preserved the PC software used by INTV Corp.

@Carl Mueller Jr's DOS based emulator (INTVPC) and dev kit ran just fine on high end 386 and 486 hardware, from what I recall.  (Not sure if it pulled a full 60Hz on 386s.)  It directly made use of the VGA's unchained planar memory mode (look up "Mode X") to get hardware pixel doubling for free as well.  That's still a notch above XT/AT class, though.  His assembler would likely move easily to anything Turbo Pascal can compile for though.

 

jzIntv and even as1600 probably don't scale down that far at this point.  I'd have to take some effort to trim the fat that's accumulated over 20 years.  Don't get me wrong: jzIntv is quite fast, but it's quite fast using techniques suited to modern hardware.  AS1600 has gained a bunch of features, but at the expense of memory bloat.  I've focused increasingly on making the modern experience reasonable.

 

@Carl Mueller Jr has taken Intellivision emulation to even smaller environments as I understand it.  I'll let him talk about those if he wants.

 

[Make a Build using INCLUDE]

Also: There's no reason to limit yourself to one file in the per-configuration directory.  If you have multiple pieces that you need to tweak differently in this way, you can do that with each of these pieces.  Make separate versions in the separate cfg_XXX directories.

[Make a Build using INCLUDE]

One trick I've used with AS1600 is to abuse the "include path" to point it to different directories to get different build configurations.  You could do something similar with IntyBASIC's library_path argument.

 

• Make a directory for each of your game configurations, e.g. cfg_1up_easy, cfg_1up_hard, cfg_2up.
• Copy intybasic_prologue.asm and intybasic_epilogue.asm into all of them, since it appears IntyBASIC only searches one directory.  (Someone correct me if that's not true.)
• Add a .bas file in each that holds the configuration-specific details.  (Note: This can INCLUDE other files!)  For example, name it game_config.bas.
• In your main game source file, simply INCLUDE "game_config.bas" (or whatever name you chose).
• When you compile the game pick the configuration by specifying one of the directories created above as the library_path.  The following will compile the three versions to three separate assembly files:
  • intybasic --title "My Game (1up Easy)" mygame.bas mygame_1up_easy.asm cfg_1up_easy
  • intybasic --title "My Game (1up Hard)" mygame.bas mygame_1up_hard.asm cfg_1up_hard
  • intybasic --title "My Game (2up)" mygame.bas mygame_2up_hard.asm cfg_2up

Then, assemble these as usual.

 

You could fold the details into separate scripts/batch files, so you can run, say, build_1up_hard to just build that variant.

 

As I said, I've used this to build variants with different features (debug code, cheats, etc.) w/ AS1600 and its -i dir flag. I see no reason why a similar trick couldn't work with IntyBASIC.

[jzintv Christmas update]

2 hours ago, intvnut said:

On my 4 CPU Linux box, make -j4 brings the compilation time down from about 3 minutes to about 1 min 20 seconds.

To be clear, that's jzIntv's compilation time.  SDL2 actually compiles faster, but they don't enable link-time optimization, and that's somewhat expensive.

[jzintv Christmas update]

2 hours ago, First Spear said:

Trying to build SDL2 (on Ubuntu 16), ended with a 1 for exit status. Probably some pathing problem, can anyone help me get a clue? I grabbed SDL 2.0.12 source and put it into an "SDL2" directory. Thanks!

 

You don't need to build jzIntv as root.  Just plain ol' make (or better, make -f Makefile.linux_sdl2) should do

 

It looks like whatever you used to unzip jzIntv didn't apply the "execute" bit to the scripts in src/buildcfg/, based on this part:

make: execvp: ./buildcfg/svn_rev.sh: Permission denied
make: execvp: ./buildcfg/svn_dty.sh: Permission denied

To fix that, run chmod +x buildcfg/*.sh from within the src directory.

 

For the rest:  jzIntv does not build or install SDL2 for you.  You'll either need to install the SDL2 devel package for your Linux distro, or compile and install SDL2 yourself.  On Ubuntu 16, sudo apt-get install libsdl2-dev should do the trick.  I'm pretty sure installing the "dev" package pulls the main libraries.  If not, sudo apt-get install libsdl2 gets the run time libraries.

 

The advantage of compiling and installing SDL2 yourself is that you'll get a newer SDL2.  According to this page, Ubuntu 16.04LTS defaults to 2.0.4, while the latest is 2.0.12.

 

For SDL2, IIRC, you can install it with something along the lines of:

(From within the SDL2-2.0.12 source top-level directory)

$ ./configure --prefix=/usr/local
... lots of configuration goes by ...
$ make -jN
... lots of compilation goes by ...
$ sudo make install

In the sequence above, replace "N" in make -jN with the number of CPUs you have, or a smaller number.  For example, if you 4 CPUs, make -j4 works reasonably well.  You can use Make's -j flag when building jzIntv as well.

 

On my 4 CPU Linux box, make -j4 brings the compilation time down from about 3 minutes to about 1 min 20 seconds.

 

BTW, I did a partial release the other day, to incorporate some bug fixes from July.  You can grab that source here:  http://spatula-city.org/~im14u2c/intv/dl/jzintv-20200822-src.zip

 

Once I get a chance to build R-Pi and Linux builds, I'll make it the official release.  The bugfixes are fairly minor.

 

[Daniel Bass's RAINBOW - 240 additional colours for your Inty]

If you recorded an AVI, I believe jzIntv shouldn't drop any frames in the AVI itself.  If you're seeing frame drops in the AVI, let me know.

 

As for the actual display, I seem to get more consistent display synchronization in full-screen than in windowed mode.  Also, SDL2 is lightyears better than SDL1 so far in my experience.

[Unpunched INTV boards]

4 hours ago, Rev said:

Any special dates or anything I should be watching for?  I have another two giant boxes of PCBs to sort through. 

Nothing comes to mind other than 1979 was the introduction of the system.  IIRC, it was test-marketed at the end of 1979.

[Unpunched INTV boards]

4 hours ago, Rev said:

Not to take over Steves thread too much. But here is an interesting PCB I found in my search through 1000+ circuit boards. 
 

So far only 1 found like this. Oh my! A rare circuit board variation? 
 

SYL 11 V1 Revision E 7159.    Is it a Sylvania branded board?  Shiny gold 🤩
 

 

Wow, a board with 1979 ROMs, but no RF shield.  (7947 is the date code: 1979, work week 47.)

 

Somewhere in my storage unit I have a few dozen bare boards.  If I come across them, I'll try to remember to photo them for the PCB database.

 

Are you also cataloging the ROM numbers you find?  e.g. RO3-9504-107 / RO3-9504-207?  The 3-digit code identifies the contents of the ROM.

 

And yes, SYL is likely Sylvania.  Makes sense as they were an early manufacturing partner.

[Unpunched INTV boards]

14 hours ago, cmart604 said:

Nerd. 

[ECS Lite? (RAM+PSG)]

1 hour ago, KEslinger said:

So if I develop games that require ECS.bin, what limitations will have on distribution of the ROM?

If you're developing a game that relies on the ECS from IntyBASIC, then end users can use either the phony ecs.bin I created above, or the real ecs.bin.  IntyBASIC does not depend on its contents.  The phony ecs.bin I created above is completely unencumbered.

1 hour ago, KEslinger said:

I assume the ECS.bin would also be required for anyone wanting to play it via jzintv or flashcarts?

It's only needed for the emulator.  And, in fact, I could easily tweak the emulator to not require the binary at all for IntyBASIC games that just want to use the ECS's additional sound capabilities, and possibly its extra RAM, controller, or keyboard support.

 

For someone playing on real hardware via a flashcart, they'll need an actual ECS unit to get the additional functionality.  The additional functionality isn't part of the ECS ROM.  It's in the extra sound chip and RAM chip that the ECS provides.

 

1 hour ago, KEslinger said:

What if I was to get a physical board printed, will the Intellivsion series have any issues?

Same deal:  If you're playing on real hardware, and you want ECS functionality, you need an actual ECS.

 

So far, I believe the most popular use of the ECS is to add richer sound effects/music to games.  If you design things appropriately, your game can fall back to simpler sound effects and music when the ECS is not attached. 

 

That way, folks with an ECS get enhanced capability, and folks w/out an ECS still get to play.  That's what I did with Space Patrol, for example.

[ECS Lite? (RAM+PSG)]

27 minutes ago, KEslinger said:

@intvnut where do put the ecs.bin file in the folder structure?

Next to wherever you have exec.bin and grom.bin.

 

I haven't looked at the IntyBASIC SDK, so I don't know where it puts those.

[ECS Lite? (RAM+PSG)]

Just now, carlsson said:

If it is enough with a block of empty space, I'm sure a recipe could be cooked up in IntyBASIC to build your own ECS placeholder ROM.

IntyBASIC brings too much baggage—the prologue/epilogue code.

 

Just assemble this as ecs.bin:

  ORG $1000 ; this value is unimportant.
  REPEAT 12*1024
  DECLE -1
  ENDR

That's it.  You can discard the ecs.cfg that AS1600 will generate. It's garbage and it's not needed. Feed the ecs.bin file to jzIntv, though, and homebrews should start working.

[ECS Lite? (RAM+PSG)]

2 hours ago, carlsson said:

I don't know if there is a "mini-ECS" replacement just like there is a mini-EXEC and mini-GROM.

Once upon a time, I created a file with 24KB of 0xFF bytes as a dummy ecs.bin.  This is sufficient to get homebrews running that just want the extra PSG and/or RAM.

 

I think there's still copies of it floating around, as every so often I see a bug report that involves trying to use it with one of the original ECS games.

 

I suppose if it makes sense, I can add a "ECS lite" mode to jzIntv that skips loading the ECS ROM image.  With a small tweak to IntyBASIC, it could even tell jzIntv to fall back to that mode if ecs.bin is unavailable.

[ECS Sound / Music question]

I suppose an ON GOTO or ON GOSUB might be easier to read than IF THEN ELSE in some cases.  Probably also marginally cheaper if done right.

[[IntyBASIC] DATA VARPTR question]

9 hours ago, carlsson said:

levels: DATA VARPTR levell1(0), VARPTR level2(0), VARPTR level3(0) 
level1: DATA 3,2,5,8 
level2: DATA 4,2,4,6,8 
level3: DATA 5,1,3,5,7,9

 

 

You could probably do something like this:

 

levels: DATA VARPTR level1(0) - VARPTR levels(0), VARPTR level2(0) - VARPTR levels(0), VARPTR level3(0) - VARPTR levels(0) 
level1: DATA 3,2,5,8 
level2: DATA 4,2,4,6,8 
level3: DATA 5,1,3,5,7,9

 

And then do this:

#curlvl = levels(lvl-1)

  FOR i=1 TO levels(#curlvl):PRINT AT levels(#curlvl+i)*20+7,"*   *":NEXT

I'm not sure it buys you anything, and it may generate worse code.  I suppose you could try it and see.

 

 

[How do you open an Intellivision Cart Shell?]

I find it amusing they chose Dragster, a game that lasts about 6 seconds featuring cars that nominally go 300MPH, to pair with Slow Ride.

 

As for Dad, here's what happened:

 

Off camera, Meg and her neighbor Sally are sitting on the couch talking.  Burt's watching the kids at the TV while Sally's husband Bob's off grabbing a beer.

 

Meg:  "This game only lasts 6 seconds?"

Sally:  "That's longer than Bob does!"

Meg and Burt start to snicker.

Bob returns, beer in hand:  "What'd I miss?"

 

Meg, Sally, and Burt just lose it at that point, busting a gut laughing.

 

Bob, confused: "What?  What is it?"

Burt: "Nothin', Dragster!"  *everyone starts laughing again*

 

 

[Unpunched INTV boards]

Cool!  Looks like these were almost fully manufactured, and stopped short of the final cuts to put them in a cartridge shell.  

 

For the folks that haven't dealt with PCB manufacturing, a little background. Typically PCBs are made in a big panel, and then scored/v-grooved, or drilled/routed to form smaller PCBs.  The drilled/routed ones have some small bridges of material, called tabs, that keep them hanging in the panel.  A panel full of PCBs ends up looking something like this.

 

 

It looks like @BSRSteve's boards were mostly, but not completely, removed from the panel.

 

You can see in BSRSteve's photos that there's a small bridge of material with no solder-mask that remains between each board.  (Solder-mask is the green protective layer.)  Those are called tabs.

 

If you pop open a regular cartridge, you'll see a couple rough spots on the outer edges of many Intellivision cartridge PCBs.  Those were likely from tabs like these.  My guess is that whatever manufacturing automation they used must benefit from feeding boards 4-up like this.  I don't know if that would only apply to populating the ROMs and wave-soldering, or if whatever machine stuffs the cartridge shells also benefits (assuming it was machine automated).

 

What that also means is that we have a new frontier in variant collection!  The two outer boards in each group of 4 has its outer edge routed smooth.  Those will only have breakaway tabs on the left or right edge.  Thus, we now have "left tab", "right tab", and "left & right tab" board variants!  

 

You can see left-tab and right-tab variants already on IntvFunHouse...  (The upper two boards on the left.)

 

[Bitmap Fonts Not Copyrightable!]

5 hours ago, bhall408 said:

Did you put garbage in that space in the miniGROM?

Originally I did not.  The original MiniGROM was a tweaked version of the CGA font, with the CGA pictographs in the upper part of the GROM.

 

It turns out that the idea of basing a replacement on CGA had some precedent:  The alphanumeric portion of the TutorVision font is also a tweaked version of the CGA font.  Much less tweaked than the version in final version of MiniGROM, in fact.

 

I guess eventually we replaced it with a more heavily tweaked version of the CGA font, added the Intellivision pictograph tiles, and added some random tiles at the end.  Compare and contrast:

• http://spatula-city.org/~im14u2c/intv/grom_svg/
• http://spatula-city.org/~im14u2c/intv/minigrom_svg/

[jzintv Christmas update]

16 hours ago, Zendocon said:

The window border does appear when the jzintv window has focus.  I'm just not getting a titlebar.  Again, if I switch back to twm, I do get the titlebar, so it's however wm2 gets the title from the SDL2 build.

I dug into the SDL2 source code. On a call to SDL_SetWindowBordered(), if the window manager does not support _MOTIF_WM_HINTS, then the code blindly sets the WM_TRANSIENT_FOR hint regardless of the border enable flag, marking the window as transient (aka. a pop-up dialog).

 

Looking at the wm2 source code, it won't display the title tab on transient windows, if I understood the code correctly.  And, it doesn't seem to look for the _MOTIF_WM_HINTS, either.

 

I would say try commenting out the calls to SDL_SetWindowBordered().  However, it appears that won't work:  SDL unconditionally calls the internal SetWindowBordered function as part of X11_CreateWindow.

 

I don't know how comfortable you are with recompiling SDL2 yourself, and pointing jzIntv to your own SDL2 compile.  But, if you are comfortable with it, we can try a simple hack of commenting out this call to X11_XSetTransientForHint() (or conditionalize it on border == SDL_FALSE) and see if that fixes the issue.

 

I could also try a hack that just "goes around" SDL's X11 driver and manages the WM_TRANSIENT_FOR property directly on builds that support X11.  This wouldn't be the first place jzIntv went around SDL2 to work around an SDL2 bug.

 

That would be here.  On MacOS X devices, the Metal graphics backend leaves the target color space unset, resulting in "unmanaged color."  Now, anyone who has participated in the "What are the right colors?" threads might guess, that throws any attempt at getting it correct right out the window.  It might look right on my monitor and wrong on yours.  However, it seems that with a single monitor, it seemed to mostly do the right thing, giving me something like sRGB.  Mostly.

 

With multiple monitors with different color profiles, the unmanaged mode does seriously weird things.  In particular, the pool of render buffers that Metal uses can end up using a mix of color profiles if you drag the window between monitors.  In the best case scenario, it uses the starting monitor's color profile everywhere.  The colors look right on one monitor, and wrong on the others.  In the worst case scenario, it toggles between the different monitors' color profiles every frame.  The result is a window that shimmers weirdly:  It flickers between multiple different color profiles.  I lost a couple days figuring that one out.

 

One I figured it out, the fix was simple:  Ask SDL for a pointer to the Metal layer (which fortunately it has a hook for on OS/X), and manually set our color space to the device-independent sRGB color space.  Now when you drag a window between monitors, the colors match and you never get the weird shimmer I mentioned.  That fix is in the recent release.

 

Now just to add to the fun future possibilities:  I could also set the color space to DisplayP3 instead, and get something that can display the NTSC color gamut, and actually have a chance at correct colors!  But... it requires out-of-range colors passed directly to Metal, and SDL doesn't really support that.  There may be a way around it by abusing palettes and going around SDL2 to create a palette with the full-gamut colors.  But, that's way more science project than I care to bite off, and it only benefits Mac.

 

I just want to get all the immediate issues causing folks heartburn with jzIntv off my plate so I can stop thinking about jzIntv for a bit and get focused on LTO Flash again.

[jzintv Christmas update]

14 hours ago, Zendocon said:

I forgot to mention, the SDL2 build is still returning 1 when exiting on user request.

I figured out what's going on with that. After printing the "normal exit" message, I call cfg_dtor(), which wipes the value of the exit flag, and leads to me returning 1.  It'll be fixed in the next release.

 

14 hours ago, Zendocon said:

I'm just not getting a titlebar.  Again, if I switch back to twm, I do get the titlebar, so it's however wm2 gets the title from the SDL2 build.

I do set the window title, initially to "jzintv" in SDL_CreateWindow, and updating later with the cartridge name and year via SDL_SetWindowTitle.

 

Can you report which video driver and render backend --gfx-verbose report for the SDL2 build?

[jzintv Christmas update]

18 hours ago, Zendocon said:

Both builds are behaving the same way as before.  With my proprietary window manager, the SDL1 build appears in the top left corner with a titlebar, and the SDL2 build appears in the center of the screen with no titlebar.  As for the mouse, with SDL1 the pointer disappears when it's hovered over the window, but not with SDL2.  That may explain the difference in reaction to mouse "input events".

The calls to SDL_ShowCursor in gfx/gfx_sdl2.c control whether jzIntv hides the mouse cursor when it's over the window.  I did change that behavior between SDL1 and SDL2 and was planning on possibly backporting the change to SDL1, actually.

 

You can try changing them to always hide the mouse (SDL_ShowCursor(SDL_DISABLE)) and see if that improves the stutters you see when the mouse moves.  Or, it's possible you're seeing the freezes these folks also saw: https://github.com/kivy/python-for-android/issues/2169

 

I still have no idea why it doesn't show you the window border.  I call SDL_SetWindowBordered and set it to SDL_TRUE.  I did see a comment about the Wayland display target lacking client-side window decorations here: https://bugzilla.libsdl.org/show_bug.cgi?id=3948#c3

If you add the command line flag --gfx-verbose, it'll print what video and render driver it's selected.

 

[jzintv Christmas update]

1 minute ago, intvsteve said:

Then there is no file extension at all on the Lives! and Rocks! CDs. 😛

I believe that's true on the Mac "side" of the disk.  On the PC "side," I see bin+cfg on Lives, and itv+cfg on Rocks.