Jump to content

Photo

Alpha 0.35 Official Release


21 replies to this topic

#1 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,680 posts
  • begin 644 contest

Posted Thu Aug 25, 2005 11:29 PM

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.

Attached Files



#2 Jess Ragan OFFLINE  

Jess Ragan

    Phanto of the Opera

  • 10,188 posts
  • Keys and Thank You
  • Location:The Arid Zone

Posted Thu Aug 25, 2005 11:57 PM

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

JR

#3 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,680 posts
  • begin 644 contest

Posted Fri Aug 26, 2005 12:53 AM

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

JR

View Post

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.

#4 Dan Iacovelli OFFLINE  

Dan Iacovelli

    Quadrunner

  • 6,071 posts
  • Location:westchester,IL

Posted Fri Aug 26, 2005 7:12 AM

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.

#5 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,616 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Fri Aug 26, 2005 8:10 AM

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

View Post


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:
  • A high-detail ROM-based PF with more sprites.
  • A low-detail RAM-based PF with fewer sprites.
I hope this is reasonably clear?

Chris

Edited by cd-w, Fri Aug 26, 2005 8:13 AM.


#6 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Fri Aug 26, 2005 9:10 AM

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.

#7 cd-w OFFLINE  

cd-w

    Stargunner

  • 1,616 posts
  • Juno First!
  • Location:Glasgow, UK

Posted Fri Aug 26, 2005 9:19 AM

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.

View Post


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 by cd-w, Fri Aug 26, 2005 9:19 AM.


#8 batari OFFLINE  

batari

    )66]U('=I;B$*

  • Topic Starter
  • 6,680 posts
  • begin 644 contest

Posted Fri Aug 26, 2005 2:34 PM

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... :dunce:

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.

#9 vdub_bobby OFFLINE  

vdub_bobby

    Quadrunner

  • 5,832 posts
  • Boom bam.
  • Location:Seattle, WA

Posted Fri Aug 26, 2005 3:10 PM

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.

#10 attendo OFFLINE  

attendo

    Chopper Commander

  • 226 posts
  • Location:nl

Posted Sat Aug 27, 2005 7:05 AM

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.

View Post

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 by attendo, Sat Aug 27, 2005 7:51 AM.


#11 gambler172 OFFLINE  

gambler172

    River Patroller

  • 3,337 posts
  • none
  • Location:germany

Posted Sat Aug 27, 2005 10:17 AM

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.

View Post

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.

View Post

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

#12 kisrael OFFLINE  

kisrael

    HMBL 2600 coder

  • 4,071 posts
  • Location:Boston Burbs, MA

Posted Sat Aug 27, 2005 10:48 AM

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...

#13 attendo OFFLINE  

attendo

    Chopper Commander

  • 226 posts
  • Location:nl

Posted Sat Aug 27, 2005 11:38 AM

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...

View Post


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 by attendo, Sat Aug 27, 2005 11:39 AM.


#14 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,867 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Aug 27, 2005 3:12 PM

New IDE version will come soon..

View Post

Cool.

#15 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,867 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Aug 27, 2005 3:41 PM

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:
anim01messup.gif

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

Edited by Random Terrain, Wed Sep 7, 2005 11:09 PM.


#16 Dan Iacovelli OFFLINE  

Dan Iacovelli

    Quadrunner

  • 6,071 posts
  • Location:westchester,IL

Posted Sat Aug 27, 2005 3:57 PM

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:
anim01messup.gif

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

View Post


I had the same problem with past version as well the new version works great.
(also can wait for new version of IDE)

#17 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,566 posts
  • Location:South Carolina, USA

Posted Sat Aug 27, 2005 7:38 PM

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

View Post


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 by SeaGtGruff, Sat Aug 27, 2005 7:51 PM.


#18 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,566 posts
  • Location:South Carolina, USA

Posted Sat Aug 27, 2005 8:00 PM

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...

View Post


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

#19 mos6507 ONLINE  

mos6507

    River Patroller

  • 4,916 posts

Posted Tue Aug 30, 2005 1:42 PM

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.

#20 Luigi301 OFFLINE  

Luigi301

    Moonsweeper

  • 372 posts

Posted Tue Aug 30, 2005 8:45 PM

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.

#21 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,867 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Aug 30, 2005 8:54 PM

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.

View Post

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.

#22 attendo OFFLINE  

attendo

    Chopper Commander

  • 226 posts
  • Location:nl

Posted Sat Sep 10, 2005 11:25 AM

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.

View Post

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users