Alpha 0.35 Official Release

[+batari]

This is basically Alpha 0.3 with the following bugfixes:

 

include command now works

bit operations now compile properly

4.4 fixed point math didn't sign-extend when adding to 8.8

Fixed point math adds/subtracts by 1.xx no longer drop the .xx

ballheight or missileXheight of 0 or 1 no longer breaks the kernel

Fixed batch file to work with Windows 95/98/ME

More than one || per program now allowed

Maybe more that I can't remember now

 

I hope that these bugfixes are enough to allow people to actually use bB...! Let me know if there are any problems.

batari_basic_alpha35.zip

batari_basic_alpha35_source.zip

[Jess Ragan]

When's the new graphics kernal going to be implemented?

 

JR

[+batari]

When's the new graphics kernal going to be implemented?

 

JR

918991[/snapback]

A couple of weeks, probably...

 

For those who want to know why it's not in place already, here's the technical reasons:

 

The issue is with memory organization. The current kernel is very flexible in that graphics data can be put nearly anywhere and it will work just fine, and the pointer for each graphic needs to be set only once.

 

The new kernel imposes greater limitations on where graphics data can be placed (in that you can only place graphics data in the first ~160 bytes of any given 256-byte page.) I am still trying to figure out how bB will handle this without just filling the ~100 bytes of each graphics page with zeros, blatantly wasting ROM space. I'd also like to keep the memory organization transparent to the programmer unless he wants to see the asm file.

 

Furthermore, the pointer for each graphic needs to be set every frame, and automatic bounds checking is required because xpos values over about 165 will cause bad things to happen in the multisprite kernel.

 

I don't think I can make the new kernel as flexible as the old in terms of memory organization, however, since (at current count) this requires 6 extra cycles per scanline, which are simply not there.

 

If anyone has suggestions of how to solve these issues, let me know.

[Dan Iacovelli]

the new release works great. I'm use 2600ide with it.

I don't know if this has something to do with the realese or the ide

but the dos screen freezes and you have to close it down manualy instead of it closing it down automatic.

[cd-w]

If anyone has suggestions of how to solve these issues, let me know.

919008[/snapback]

 

I can see this will be a difficult one to solve! It sounds like you need some kind of packing algorithm which splits the code from the data, and stores the data in the correct place in each page.

 

Alternatively, if you only allowed a ROM-based PF with the multi-sprite kernel, you could use the extra RAM to store the sprite data and avoid the alignment issues. My assumption is that the ROM-based PF data wouldn't need to be carefully aligned. You would only store 2 sprite frames in RAM (Player 0 & 1) and copy any new sprite data from ROM->RAM between screens. This would give you two kernel options:

1. A high-detail ROM-based PF with more sprites.
   
2. A low-detail RAM-based PF with fewer sprites.
   

I hope this is reasonably clear?

 

Chris

Edited August 26, 2005 by cd-w

[vdub_bobby]

The new kernel imposes greater limitations on where graphics data can be placed (in that you can only place graphics data in the first ~160 bytes of any given 256-byte page.)  I am still trying to figure out how bB will handle this without just filling the ~100 bytes of each graphics page with zeros, blatantly wasting ROM space.  I'd also like to keep the memory organization transparent to the programmer unless he wants to see the asm file.

 

Furthermore, the pointer for each graphic needs to be set every frame, and automatic bounds checking is required because xpos values over about 165 will cause bad things to happen in the multisprite kernel.

First, don't you mean the last ~160 bytes of a page?

 

Second, are setting the pointers every frame and automatically truncating X-values that much of a problem?

 

The memory stuff, though...hmmmm...maybe I'll take another look at that kernel, see if I can do something about those things.

 

But I would think the best thing to do is to go through once, placing all the graphics where they need to be, and then start filling in the beginning of those pages with whatever short subroutines there are. There's probably no way to completely optimize ROM space using an algorithm, but you could probably get close enough that way for it to work.

Alternatively, if you only allowed a ROM-based PF with the multi-sprite kernel, you could use the extra RAM to store the sprite data and avoid the alignment issues.

In the new kernel the PF uses something like 20 bytes of RAM - since the kernel allows up to 6 sprites on screen at once, there is just no way you could store the sprite data in RAM, unless you swapped it out mid-kernel - which most of the time would take too long and all of the time would take a variable number of cycles, making it impractical.

[cd-w]

In the new kernel the PF uses something like 20 bytes of RAM - since the kernel allows up to 6 sprites on screen at once, there is just no way you could store the sprite data in RAM, unless you swapped it out mid-kernel - which most of the time would take too long and all of the time would take a variable number of cycles, making it impractical.

919142[/snapback]

 

OK, I see that isn't going to work, since you also need the colour data for the sprites I was thinking that the multisprite kernel just allowed you to use all of the sprites (including the missiles and ball), but not more than one copy of each.

 

Chris

Edited August 26, 2005 by cd-w

[+batari]

The new kernel imposes greater limitations on where graphics data can be placed (in that you can only place graphics data in the first ~160 bytes of any given 256-byte page.)  I am still trying to figure out how bB will handle this without just filling the ~100 bytes of each graphics page with zeros, blatantly wasting ROM space.  I'd also like to keep the memory organization transparent to the programmer unless he wants to see the asm file.

 

Furthermore, the pointer for each graphic needs to be set every frame, and automatic bounds checking is required because xpos values over about 165 will cause bad things to happen in the multisprite kernel.

First, don't you mean the last ~160 bytes of a page?

Yeah...

Second, are setting the pointers every frame and automatically truncating X-values  that much of a problem?

No, not a big deal... Just a little more programming effort to get this in. Nothing I can't do.

The memory stuff, though...hmmmm...maybe I'll take another look at that kernel, see if I can do something about those things.

Maybe a WSYNC at cycle 71 of the scanline where you do the GRPx writes would allow for the extra cycle needed for page crossings, but you need 5 cycles for this.

But I would think the best thing to do is to go through once, placing all the graphics where they need to be, and then start filling in the beginning of those pages with whatever short subroutines there are.  There's probably no way to completely optimize ROM space using an algorithm, but you could probably get close enough that way for it to work.

I've been thinking about this - It's a conundrum. bB doesn't know how big each module is before it gets sent to DASM, so it can't organize memory this way without help. One could make DASM do it by putting a big mess of conditional compilation stuff in the final asm, but this is not a good idea, I think.

 

One option is to pass module size to bB via a comment in the modules. This would be a lot of work to get it right, but if I did, then it would make new kernels easier to write for bB.

[vdub_bobby]

The memory stuff, though...hmmmm...maybe I'll take another look at that kernel, see if I can do something about those things.

Maybe a WSYNC at cycle 71 of the scanline where you do the GRPx writes would allow for the extra cycle needed for page crossings, but you need 5 cycles for this.

I took a look at the kernel again today, and I don't really think that I can fit any WSYNCs in there without completely rewriting it.

 

The problem is that when you are trying to do so many things in a kernel the time during the horizontal blank (and near to it) is so precious, because that's when you can change the graphics registers without screwing up the onscreen display.

 

I'll look some more, but if you have hopes of more, and more complicated, kernels, you should probably buckle down and figure out how to automagically arrange data and code in the ROM, since if it isn't necessary for this kernel (and it probably is), then it will surely be necessary for others.

 

I've written very few kernels that didn't have *some* limits on where the graphics data could be placed; at the very least that the data couldn't cross a page boundary.

[attendo]

the new release works great. I'm use 2600ide with it.

I don't know if this has something to do with the realese or the ide

but the dos screen freezes and you have to close it down manualy instead of it closing it down automatic.

919082[/snapback]

Hi,

 

Finally have a little bit more time and I started working again on a new version of the IDE hope to release it within a week of 2 or 3. This version will have some improvements and will be fully compatible with the new Batari Basic version.

 

In the meantime you can just remove the "pause" command in "2600baside.bat" if your using the IDE.

 

Greets.

Edited August 27, 2005 by attendo

[gambler172]

the new release works great. I'm use 2600ide with it.

I don't know if this has something to do with the realese or the ide

but the dos screen freezes and you have to close it down manualy instead of it closing it down automatic.

919082[/snapback]

Hi,

 

Finally have a little bit more time and I started working again on a new version of the IDE hope to release it within a week of 2 or 3. This version will have some improvements and will be fully compatible with the new Batari Basic version.

 

In the meantime you can just remove the "pause" command in "2600baside.bat" if your using the IDE.

 

Greets.

919631[/snapback]

Hi

how can i use IDE with the new 0.35 version?Or could you post a new IDE version?

greetings gambler172

[kisrael]

An idea for future releases...would it be possible to move the .txt files and help.html to a doc/ directory, and all the .asm files to lib/ or asm/ ? .h would be nice to move to if you can do that without confusing DASM... it's just a bit messy to see all those files in one flat directory...

[attendo]

An idea for future releases...would it be possible to move the .txt files and help.html to a doc/ directory, and all the .asm files to lib/ or asm/  ?  .h would be nice to move to if you can do that without confusing DASM... it's just a bit messy to see all those files in one flat directory...

919698[/snapback]

 

I agree, it would then look more cleaner and organized.

 

Hi

how can i use IDE with the new 0.35 version?Or could you post a new IDE version?

icon_confused.gif greetings gambler172

 

Just download the new bB 0.35 version and replace all old files, you should probally remove the line that says "pause" in ,the new, "2600baside.bat" it should then work. New IDE version will come soon..

Edited August 27, 2005 by attendo

[+Random Terrain]

New IDE version will come soon..

919714[/snapback]

Cool.

[+Random Terrain]

I was blocked from AtariAge for a couple of days because of some DNS error, but now I'm back and I'm happy to say that my test program below now works with no strange problems:

 

 rem * Create alias for each variable.
 dim blockx = a
 dim blocky = b
 dim delay = d

 rem * Setup.
 COLUPF = 90 : delay = 0
 blockx = 16 : blocky = 5


 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 drawscreen

 rem * Begin delay.
 delay = delay + 1
 if delay < 3 then goto gameloop
 delay = 0
 rem * End delay.

 rem * Delete block and move it to new position.
 pfpixel blockx blocky off
 if joy0up && blocky > 1 then blocky = blocky - 1
 if joy0down && blocky < 10 then blocky = blocky + 1
 if joy0left && blockx > 1 then blockx = blockx - 1
 if joy0right && blockx < 31 then blockx = blockx + 1
 if joy0fire then score = score + 1
 pfpixel blockx blocky on

 goto gameloop

This runs perfectly now, but it kind of looked like this using the last version of bB:

 

I don't know what caused that, but I'm glad it's fixed.

Edited September 8, 2005 by Random Terrain

[Dan Iacovelli]

I was blocked from AtariAge for a couple of days because of some DNS error, but now I'm back and I'm happy to say that my test program below now works with no strange problems:

 

 rem * Create alias for each variable.
 dim blockx = a
 dim blocky = b
 dim savex = c
 dim savey = d
 dim delay = e

 rem * Setup.
 COLUPF = 90 : delay = 0
 blockx = 16 : blocky = 5
 savex = 16 : savey = 5

 rem * Main game loop starts here.
gameloop

 scorecolor = 158
 drawscreen

 rem * Begin delay.
 delay = delay + 1
 if delay < 3 then goto gameloop
 delay = 0
 rem * End delay.

 rem * Delete block and move it to new position.
 if joy0up && blocky > 1 then savey = savey - 1
 if joy0down && blocky < 10 then savey = savey + 1
 if joy0left && blockx > 1 then savex = savex - 1
 if joy0right && blockx < 31 then savex = savex + 1
 if joy0fire then score = score + 1
 pfpixel blockx blocky off
 blockx  = savex : blocky = savey
 pfpixel blockx blocky on

 goto gameloop

This runs perfectly now, but it kind of looked like this using the last version of bB:

 

I don't know what caused that, but I'm glad it's fixed.

919804[/snapback]

 

I had the same problem with past version as well the new version works great.

(also can wait for new version of IDE)

[SeaGtGruff]

Hi

how can i use IDE with the new 0.35 version?Or could you post a new IDE version?

greetings gambler172

919681[/snapback]

 

I'm using 2600IDE with batari BASIC 0.35 without any trouble. I did have trouble initially, but it was the batch file, not 2600IDE itself. Edit your 2600baside.bat file so it says the following:

 

@echo off
preprocess<%1 | 2600basic.exe>bB.asm
concatenate>%1.asm
dasm %1.asm -f3 -o%1.bin

 

If that doesn't help, post a description of what's happening (or not happening).

 

Michael Rideout

Edited August 28, 2005 by SeaGtGruff

[SeaGtGruff]

An idea for future releases...would it be possible to move the .txt files and help.html to a doc/ directory, and all the .asm files to lib/ or asm/  ?  .h would be nice to move to if you can do that without confusing DASM... it's just a bit messy to see all those files in one flat directory...

919698[/snapback]

 

You can create subdirectories to help you organize things better. As far as not confusing DASM, you just need to edit your 2600baside.bat file and modify the commands as needed for the new subdirectories.

 

Post a list of subdirectories you want to use, and what files would be in them, and I'll set mine up to work that way, then post the changes you'll need to make to the batch file. Be specific-- which subdirectory will DASM be in, which subdirectory will the .ASM files be in, which subdirectory will the other .EXE files be in, etc.

 

Michael Rideout

[mos6507]

Finally have a little bit more time and I started working again on a new version of the IDE hope to release it within a week of 2 or 3. This version will have some improvements and will be fully compatible with the new Batari Basic version.

 

Can you add color coding anytime soon?

 

I use Textpad normally and really like the color coding.

[Luigi301]

Now I have to remove all these hacks to get it to work in 0.2... upgrading to vanilla 0.35 really broke my program badly.

[+Random Terrain]

Now I have to remove all these hacks to get it to work in 0.2... upgrading to vanilla 0.35 really broke my program badly.

922080[/snapback]

That's why I was holding back and only playing around. It's nice to have this version that is working better. Now it's time to get off my lazy butt and actually make something. Oh wait, I have to sit on my lazy butt to do it, so I don't have to get up.

[attendo]

Finally have a little bit more time and I started working again on a new version of the IDE hope to release it within a week of 2 or 3. This version will have some improvements and will be fully compatible with the new Batari Basic version.

 

Can you add color coding anytime soon?

 

I use Textpad normally and really like the color coding.

921696[/snapback]

Hi thanks for the suggestion, was also thinking about that. Perhaps i'll implement it but the language im using isn't very fast. To code certain words in the correct color means to check all text in one (or more) line everytime an enter or space or ) or ..etc. is made/pressed which maybe slows down the program and writing code to much. i'll check it out sometime.