GoSub for INTV

[freewheel]

 

BTW, maybe isn't clear enough in manual, but same as standard BASIC, IntyBASIC allows to use the colon character for putting several statements in same line:

 

> if room=20 and keyhave=0 then print at 102 color 5,"\315":print at 122,"\315":print at 177," ":print at 197," "

 

 

I don't think it's in the manual at all. I learned it from your sample programs (which were INVALUABLE, I must say). Maybe add a line that you can do this in the manual for the next release

 

(Sorry for hijacking the GoSub thread for IntyBASIC comments)

[catsfolly]

 

It's actually at the very top (and logically, I think explaining DIM should be right after variables). And one is incorrect:

 

 

I haven't actually tested yet, but I'd love to know if it's 16 or 32 16-bit vars. I use them a lot for fancy MOB manipulation and I'm probably pushing 16 on every basic game I do.

 

Question for you - it's the same memory space, no? Couldn't you just have X bytes for all variables, and let the developer choose how many of each they need? Or is there an architectural reason why you limit each by size? Or is it just easier for the compiler (and warnings)?

In a word, no. It's not all the same space.

There are three kinds of ram in the Intellivision.

 

1. The scratchpad ram - 256 bytes by 8 bits wide.

 

Intellivision wiki says:

The Scratchpad RAM is a 256 byte RAM mapped at $100 - $1EF. The last 16 bytes of the Scratchpad cannot be accessed, since the PSG maps to where those bytes would ordinarily reside. This memory is 8 bits wide. The upper 8 bits of each value stored here read as 0. On writes, the RAM ignores the upper 8 bits of the value written.

 

2. System RAM - this is 16 bits wide, and is used for backtab, and the stack, and 16 bit variables. In IntyBasic, much of this ram is used by IntyBasic's own routines to play music or scroll the screen or print, etc...

 

3. Graphics Ram or GRAM - is used for custom character definitions.

 

Catsfolly

[catsfolly]

Hey gang. I put in a secret level select code. Well, I guess it's not secret any more. On controller 2, type in the two-digit level number you want to start at and press fire on controller 1. For example, if you wanted to start on level 7, you'd type in 0, then 7 for 07. Note that levels 22-30 are broken because I haven't worked on them yet. I plan to put in a secret ending for those who start on level 1 and make it to level 30. If you start on any level above 1 and make it to 30, you'd get a screen that would say "try starting on level 1."

I like the level select. Very useful!

 

Level 22 is very challenging. It is difficult to "hover" in the little box in the lower right hand corner.

Level 23 is not too bad once you get used to it.

[freewheel]

In a word, no. It's not all the same space.

 

Ah, thanks. So the compiler is basically taking space from the appropriate sections as needed, and the limits are most likely what's leftover once you factor out everything else.

 

Also, I'm going to toss this in here, for our GoSub author: your game is in fact going to be limited to 16KB, if you use IntyBASIC (at least as it stands currently). Not sure if you read the thread on that or not, but I do remember some discussion about this here a few weeks ago and many people told you that you could go far beyond this size.

Edited October 14, 2014 by freeweed

[+nanochess]

 

Ah, thanks. So the compiler is basically taking space from the appropriate sections as needed, and the limits are most likely what's leftover once you factor out everything else.

 

Also, I'm going to toss this in here, for our GoSub author: your game is in fact going to be limited to 16KB, if you use IntyBASIC (at least as it stands currently). Not sure if you read the thread on that or not, but I do remember some discussion about this here a few weeks ago and many people told you that you could go far beyond this size.

 

Not necessarily if atari2600land checks the LST file generated by assembler to verify the memory zones used by the program. (available $5000-$6FFF)

 

He then can insert ASM ORG $D000 and/or ASM ORG $F000 to access further standard 16KB (available $D000-$DFFF, $F000-$FFFF)

 

Also can simply list the CFG file to check memory zones used.

 

It's a very nice game and I'm pretty sure atari2600land still has a lot of ideas for it

[+nanochess]

 

I haven't actually tested yet, but I'd love to know if it's 16 or 32 16-bit vars. I use them a lot for fancy MOB manipulation and I'm probably pushing 16 on every basic game I do.

 

 

It's easy, just put a DIM #A(number) and play with it until the compiler complains

 

I'll check later the manual, after so many revisions it's easy to have outdated subsections

[+Tarzilla]

 

Ah, thanks. So the compiler is basically taking space from the appropriate sections as needed, and the limits are most likely what's leftover once you factor out everything else.

 

Also, I'm going to toss this in here, for our GoSub author: your game is in fact going to be limited to 16KB, if you use IntyBASIC (at least as it stands currently). Not sure if you read the thread on that or not, but I do remember some discussion about this here a few weeks ago and many people told you that you could go far beyond this size.

Nope, NOT limited to 16k. A little while ago I sent the author a modified older version with enhanced title screen, zone select screen and other suggestions...it's .bin was over 18k. All I had to do was use an ASM ORG statement in the correct place...I understand the way the memory map works and while it would be nice for the compiler to automatically do that for me, it is not a show-stopper. Intvnut has provided a wealth of expert advice to Nanochess regarding how to improve the compiler and I am very confident future versions will be enhanced with respect memory maps and other efficiency improvements...

[freewheel]

OK, then a caveat to what I said - IF you develop SOLELY in IntyBASIC and don't go mucking with ASM directly (either in your .bas or modifying the .asm output), THEN you'll run into a 16KB limit.

 

Maybe I'm being pedantic, but pretty much any limitation/bug in IntyBASIC can be gotten around by coding the ASM directly. There isn't much point in warning of/discussing issues in the compiler if we can shortcut the answer to "just modify yer ASM, kids".

[intvnut]

OK, then a caveat to what I said - IF you develop SOLELY in IntyBASIC and don't go mucking with ASM directly (either in your .bas or modifying the .asm output), THEN you'll run into a 16KB limit.

 

Maybe I'm being pedantic, but pretty much any limitation/bug in IntyBASIC can be gotten around by coding the ASM directly. There isn't much point in warning of/discussing issues in the compiler if we can shortcut the answer to "just modify yer ASM, kids".

 

For the record, I happen to agree.

 

A really quick and dirty way to avoid the 8K-word (16K byte) limit is to add this to the very end of your intybasic_prologue.asm, I think:

.

        B    compiled_code_start
prologue_code_end:
        ORG $C040
compiled_code_start:

.

and then in your intybasic_epilogue.asm, put this at the very beginning:

.

        ORG prologue_code_end

.

That accomplishes two things:

1. All of the code in the prolog / epilog will get assembled in the $5xxx range.
2. All of your code will get assembled from $C040 - $FFFF, a 16K word (32K byte) range.

That gives you about 17K words (34K bytes) to work with, of which ~1K-word is the prolog/epilog code and the other 16K-words are entirely your IntyBASIC program code and data.

 

The Intellicart, CC3, JLP, LTO Flash, Bee3, Hive, and I think even Harvey's designs all will handle that map, as will jzIntv and likely most (all?) other emulators. All that without having to put ORG directives in your .BAS file anywhere.

 

EDIT: I tried this just now and compiled one of the demos, and it had the desired effect. The ~1K of code that comes from the prolog/epilog remained in the $5xxx range, and the demo code got moved out to $C040 and beyond.

 

Note: This means you will need to provide your .CFG alongside your .BIN, or start assembling to .ROM format instead of .BIN. That's because when you provide a .BIN without a .CFG, it has an implied memory map of $5000 - $6FFF, $D000 - $DFFF, and $F000 - $FFFF. Anything else that isn't an exact subset requires a .CFG file. The .ROM format includes the memory map information directly in the .ROM file itself. (The .BIN memory map convention comes from the defacto standard, Carl Mueller Jr's INTVPC.EXE on the original Intellivision Lives! CD-ROM.)

Edited October 14, 2014 by intvnut

[freewheel]

(The .BIN memory map convention comes from the defacto standard, Carl Mueller Jr's INTVPC.EXE on the original Intellivision Lives! CD-ROM.)

 

THANK YOU. I've been wondering for a while now, how the standards for ROM files came about for INTV. I'm familiar with the history on many other systems but the ROM vs BIN/CFG has been a mystery to me - until now. I guess I coulda just asked - makes sense that you'd be the one to know this.

[+DZ-Jay]

Also, I'm going to toss this in here, for our GoSub author: your game is in fact going to be limited to 16KB, if you use IntyBASIC (at least as it stands currently).

 

[+DZ-Jay]

OK, then a caveat to what I said - IF you develop SOLELY in IntyBASIC and don't go mucking with ASM directly (either in your .bas or modifying the .asm output), THEN you'll run into a 16KB limit.

 

Maybe I'm being pedantic, but pretty much any limitation/bug in IntyBASIC can be gotten around by coding the ASM directly. There isn't much point in warning of/discussing issues in the compiler if we can shortcut the answer to "just modify yer ASM, kids".

I think we all agree that the compiler should include some means to handle this automatically (or semi-automatically).

 

In the meantime, since an elegant solution may not be easy to implement, there are clear work-around techniques that can be employed, and they happen to be in Assembly.

[intvnut]

 

THANK YOU. I've been wondering for a while now, how the standards for ROM files came about for INTV. I'm familiar with the history on many other systems but the ROM vs BIN/CFG has been a mystery to me - until now. I guess I coulda just asked - makes sense that you'd be the one to know this.

 

And the .ROM format is really just whatever Chad came up with to send bytes to the Intellicart, since he didn't want to write a .CFG parser on the Intellicart.

[intvnut]

I think we all agree that the compiler should include some means to handle this automatically (or semi-automatically).

 

I think IntyBASIC should definitely handle the memory map, if only because this is the only place in Intellivision programming where I regularly have to make clear that when I say 8K I mean 8K words.

[+DZ-Jay]

 

And the .ROM format is really just whatever Chad came up with to send bytes to the Intellicart, since he didn't want to write a .CFG parser on the Intellicart.

Maybe a topic for a different thread, but can you expound on that a bit? How do these formats differ from what Mattel used originally?

 

Keep in mind that I do not know much about hardware, so this may be a completely nonsensical question.

[freewheel]

 

I think IntyBASIC should definitely handle the memory map, if only because this is the only place in Intellivision programming where I regularly have to make clear that when I say 8K I mean 8K words.

 

Maybe this is the only place where I have to regularly make it clear than when people outside of this community (and probably most people in it) say 16KB, they mean 16KB as measured on their PC. Not too many people I know have a "word counter" tool handy anymore.

Edited October 14, 2014 by freeweed

[intvnut]

 

Maybe this is the only place where I have to regularly make it clear than when people outside of this community (and probably most people in it) say 16KB, they mean 16KB as measured on their PC. Not too many people I know have a "word counter" tool handy anymore.

 

Well, that was kinda my point, and meant to be somewhat tongue in cheek. I certainly didn't mean it in a derogatory manner. :-)

 

If you program in assembly language, you're quite familiar with addresses, and so sizes, address map, etc. are most naturally talked about in words on this machine. Talking in bytes just feels unnatural. $6000 is 4K away from $5000. Calling that 8K just seems weird. If you add 4096 to the address $5000, you get $6000. If you add 8192 to the address $5000, you get $7000. Who cares how big the file on disk is, what matters is that math on addresses works as you expect. But, a ROM that occupies $5000-$5FFF takes up 8K bytes on disk.

 

In IntyBASIC, you're insulated from addresses for the most part. You're especially insulated from ROM addresses. Your program could be assembled at $5000 or $9000 or even $5000000 if that were a valid address, and you mostly don't care. The only obvious artifact you have for measuring program size is looking at your file size on disk. You get a listing file if you ask for it, but that exposes you to the assembly code, and I think it's a valid goal to want to stick to BASIC with no assembly, and that includes looking at the IntyBASIC and AS1600 output in much detail.

 

To me, that indicates that IntyBASIC should also take on the responsibility of managing the memory map as part of that abstraction. Yeah, it's a leaky abstraction, but it should be able to plug the biggest holes over time.

Edited October 14, 2014 by intvnut

[intvnut]

Maybe a topic for a different thread, but can you expound on that a bit? How do these formats differ from what Mattel used originally?

 

Keep in mind that I do not know much about hardware, so this may be a completely nonsensical question.

 

I'm not sure it matters what on-disk formats Mattel and other OEMs used back in the day, since few or none of those disks survive, and we're unlikely to see dumps from them. They probably had some object format from their minicomputer-based assembler that ran in their PDP-11 or VAX systems (and later on IBM PCs). If it was a linkable format, it probably bears some resemblance to early COFF. Maybe someone who was there could describe the toolchains? All I know is that the earliest tools were written in DEC's BLISS language.

 

The binary files we have today were dumped from ROMs or EPROMs, and ROMs don't really have a file format per se. There's plenty of container formats that can be used to describe what should be programmed into an EPROM (Intel HEX, Motorola S-rec, flat binary, etc), and the format chosen by Carl and company was big-endian flat binary with a textual .CFG file with metadata. I imagine back in the day, they used custom tools to pull apart game object files into a series of HEX files or similar to feed to standard ROM programming tools, and there wasn't much of an emphasis on going in the reverse direction. (Such tools are still common.)

 

None of the formats back in the day were likely meant to feed an emulator, but rather just ultimately convey the assembly code through the computer and other hardware, landing ultimately in a ROM/EPROM.

Edited October 14, 2014 by intvnut

[intvnut]

Maybe this is the only place where I have to regularly make it clear than when people outside of this community (and probably most people in it) say 16KB, they mean 16KB as measured on their PC. Not too many people I know have a "word counter" tool handy anymore.

 

I guess the other thing is that even though ROM/BIN images store 16-bit wide images, and modern games can leverage the full 16-bit width, games back in the day were in 10-bit wide ROMs. The upper 6 bits of each word read as 0.

 

When comparing game sizes between contemporaries, for example an Atari 2600 game vs. an Intellivision game vs. a Colecovision game, word count is a fairer measure than byte count of the disk image. A 4Kx10 Intellivision game such the original Baseball effectively has 5K bytes of data (40960 bits) in it, but takes up 8K bytes on-disk in our simplistic .BIN format. 5K is much closer to 4K than 8K.

Edited October 14, 2014 by intvnut

[+atari2600land]

I changed level 22 around to make it a little bit easier. I also now know how to turn it into a ROM file, which is just as easy as dragging it into the .exe file. But I do have a question. In the Intellicart testrom.cfg file, it says this:

 

$0000 - $00FF = $5000 ; map first 8k to $5000 - $6FFF

 

Would I need to add another line to map the second 8k to another address? Something like $1100-$11ff = $7000 perhaps?

Edited May 30, 2015 by atari2600land

[+nanochess]

I changed level 22 around to make it a little bit easier. I also now know how to turn it into a ROM file, which is just as easy as dragging it into the .exe file. But I do have a question. In the Intellicart testrom.cfg file, it says this:

 

 

Would I need to add another line to map the second 8k to another address? Something like $1100-$11ff = $7000 perhaps?

 

Don't worry, the CFG file is automagically generated and you can list it to see how your program is using memory. (the left two numbers are the origin in BIN file and the right number is the start address in "real" ROM)

 

BTW, just revise the assembler generated LST file, check the left column (the address) and check in what part of your source code goes what address. (the IntyBASIC source code is inserted as comments in the generated assembly listing)

 

Next, just insert an statement "ASM ORG $D000" or "ASM ORG $F000" in the right position of your source code to start using these memory zones. (see again the LST file to see how it works)

 

After assembly the CFG file will reflect the new addresses used.

[+atari2600land]

In case you're wondering whether this works on a real INTV or not. It even works on an INTV2, which is more than I can say for some cartridges (cough *coleco*)

 

[intvnut]

I changed level 22 around to make it a little bit easier. I also now know how to turn it into a ROM file, which is just as easy as dragging it into the .exe file. But I do have a question. In the Intellicart testrom.cfg file, it says this:

 

 

Would I need to add another line to map the second 8k to another address? Something like $1100-$11ff = $7000 perhaps?

 

As nanochess said above, the assembler generates the correct .CFG file for you.

 

Also, if you tell it to generate a .rom, it will do so automatically. Or, just leave the extension off and it will generate both .bin and .rom at the same time:

as1600 -o gosub.bin -l gosub.lst gosub.asm     ; <-- this generates gosub.bin and gosub.cfg
as1600 -o gosub.rom -l gosub.lst gosub.asm     ; <-- this generates gosub.rom (Intellicart ROM format)
as1600 -o gosub -l gosub.lst gosub.asm         ; <-- this generates gosub.bin, gosub.cfg, and gosub.rom all in one go.

[+atari2600land]

The weird thing is the Intellicart did not want my .rom file and instead took my .bin file.

[intvnut]

The weird thing is the Intellicart did not want my .rom file and instead took my .bin file.

 

Ok, if you're directly sending bytes to the Intellicart, it wants the .ROM file contents. If you're using the GUI downloader, the older versions looked for BIN+CFG, convert that to ROM and send that down the wire. Later Intellicart GUI downloaders recognize when you've provided a .ROM and just send it down the wire as-is. I think Chad's site links to the latest Intellicart downloader, but I'll admit I'm too lazy to check right now.

 

If you're in Windows (or DOS, if you're amazingly retro), you can use an appropriate combination of MODE COM1: (or whatever your COM port is) and COPY my.rom/b COM1: to download directly to the Intellicart w/out the GUI. That won't work with a .BIN file, but it will with a .ROM file¹. (The /b flag tells the COPY command that the contents are binary, and to not muck with newlines or EOF characters or anything.) If you're on Linux or a Mac, there's an equivalent sequence of commands to directly send a .ROM to the Intellicart.

 

If you want more details, feel free to PM me, or start a new thread. I've already posted too many ostensibly off-topic comments in the GoSub thread.

 

-------------------------------------------------------------------------------

¹There are actually two versions of the .ROM format: Intellicart and CC3. They differ in the first byte and nothing else. The Intellicart format starts with 0xA8 and the CC3 format starts with 0x41. This byte forms the "baud detect byte" and is only used for serial download. It's used by the serial code on either device to automatically detect the baud rate of the incoming .ROM file. Annoyingly, the CC3's SD card reader, if I remember correctly, only recognizes .ROM files with the Intellicart baud byte though. jzIntv and LTO Flash know about both baud bytes, and you can talk the SDK-1600 tools into generating .ROM files with either the Intellicart (default) or CC3 baud byte. 99.44% time, you'll just want to ignore the CC3 baud byte version of the .ROM format.

 

Why are there two different baud bytes? On the Intellicart, Chad wrote his own autobaud code that maniacally polled the serial receive line and counted high/low transition times to determine the baud rate. It used the 10101 transitions in 0xA8 to do that measurement. On the CC3, the UART on the chip he used could autobaud based on the letter 'A' or 'a', with the idea it'd be used for a Hayes modem type application where the opening string would be "ATblah" or "atblah". Chad decided to use the hardware autobaud there. The ASCII code for 'A' is 0x41, and the ASCII code for 'a' is 0x61.

 

And if you read all that, you might be wondering... is there a third format with 0x61 (ASCII code for 'a') as the baud byte? If you look in the SDK-1600 / jzIntv source code, I have provisions for that, but nothing was ever done with it. I called the format "CC3_ADV" for "CC3 Advanced Mode," but nothing was ever done with it.

Edited October 15, 2014 by intvnut