Jump to content

Gaztee

Recommended Posts

Hello all,

 

i just thought i could post a picture that shows what kind of levels i currently have stored on the serial 2048byte-Eeprom. As discussed before, the CD-version of Impulse X stores a full set of 40 selfcreated levels (playfield designs) on MemoryTrack, while the number of levels that can be stored by the cartridge version on the serial Eeprom will depend on the design of the playfield (placement of the bricks and number of PowerUps placed) and will usually be far below 40.

 

So as you can see in the attached picture (the widely used PowerUps are not visible), i was able to store 14 different playfields on the serial Eeprom, but using only few brick types (colours) per playfield probably helped a lot ;)

 

Bye!

Matthias

 

post-2054-0-93189600-1368642529_thumb.png

Edited by Matthias
  • Like 1
Link to comment
Share on other sites

Thanks matthias. Ah if only time were in greater supply. I have the cd version and intend to buy the cartridge version once it's available. Could you code it such that the rotary control favours the modded jagpad? I find that this method is a little jerky currently. Is this possible?

Link to comment
Share on other sites

So as you can see in the attached picture (the widely used PowerUps are not visible), i was able to store 14 different playfields on the serial Eeprom, but using only few brick types (colours) per playfield probably helped a lot ;)

What compression method(s) are you using to store the level data? It'd be interesting to see the format for the level data and see if anyone can come up with some clever ways of packing to an absolute minimum... maybe something for the programming section? :-)

  • Like 2
Link to comment
Share on other sites

Thanks matthias. Ah if only time were in greater supply. I have the cd version and intend to buy the cartridge version once it's available. Could you code it such that the rotary control favours the modded jagpad? I find that this method is a little jerky currently. Is this possible?

 

While programming can compensate, this is a problem with the rotary encoders being used on some of the models being sold by individuals. I bought one of the Jag pad duo rotaries that still work as a jag pad with a switch, and I find it too sensitive for T2K (but it works), but with Kobiashi Maru, it's not only too sensitive, but I get that jerkiness that you talk about as well. And KM even checks the rotary and sets a level (for mine it sets it at 3) but that doesn't even help. I don't have Impulse X yet, but I think it'd be the same since you mentioned it. I'm going to replace my rotary encoder with a less sensitive version.

Edited by Gunstar
Link to comment
Share on other sites

Hello!

 

 

Thanks matthias. Ah if only time were in greater supply. I have the cd version and intend to buy the cartridge version once it's available. Could you code it such that the rotary control favours the modded jagpad? I find that this method is a little jerky currently. Is this possible?

 

While programming can compensate, this is a problem with the rotary encoders being used on some of the models being sold by individuals. I bought one of the Jag pad duo rotaries that still work as a jag pad with a switch, and I find it too sensitive for T2K (but it works), ...

 

In Impulse X you can change a setting called SPEED in the Controller Configuration screen to values in the range of 1 and 20 for each controller type, and these values will be stored on MemoryTrack (or the NVRAM of the cartridge). The default values for each controller type were chosen by me based on my personal experiences and predilections, but also seemed to have met the taste of the testers as well of the audience at the several Euro-Jagfests.

 

FYI:

SPEED just stands for "horizontal pixel movement of the bat per controller tick",

with the playfield being 320 pixels wide i tried to find values that would keep me from having to move the mouse too far or to turn the knob of the modded Jagpads (most of them show 36 ticks per revolution) or VCS driving controllers (16 ticks per revolution) more than two times to pan the bat over the whole playfield width.

 

Although using a SPEED value of 1 would be nice (but less than the X-axis movement of the ball, therefore 2 is used for the Joypads in Port 1), 2 is used as the default value for digital mice, 8 is chosen for modded Rotary-Jagpads and i think 16 or 20 for VCS driving controllers.

 

Unfortunately there is a sideeffect when using higher SPEED values: The angle in which the ball bounces back from the bat depends on where the ball hits the bat, but with higher SPEED values you can't position the bat as accurate as you would wish.

 

 

Kind regards

Matthias

Link to comment
Share on other sites

While programming can compensate, this is a problem with the rotary encoders being used on some of the models being sold by individuals. I bought one of the Jag pad duo rotaries that still work as a jag pad with a switch, and I find it too sensitive for T2K (but it works), but with Kobiashi Maru, it's not only too sensitive, but I get that jerkiness that you talk about as well. And KM even checks the rotary and sets a level (for mine it sets it at 3) but that doesn't even help. I don't have Impulse X yet, but I think it'd be the same since you mentioned it. I'm going to replace my rotary encoder with a less sensitive version.

 

thanks Gunstar from what I remember when I last played it , it was twitchy on all settings. This is with a duo pad I modified myself.

Link to comment
Share on other sites

Kobayashi Maru and Impulse X deal with rotary controller adjustments in very different ways. I don't get on with the IX rotary at all with my spinners - there's no happy medium for my personal taste. That's why I played it with mouse.

Link to comment
Share on other sites

Hello!

 

What compression method(s) are you using to store the level data? It'd be interesting to see the format for the level data and see if anyone can come up with some clever ways of packing to an absolute minimum... maybe something for the programming section? :-)

 

There are 40 playfields, each playfield consists of a grid of 18 rows with 20 columns of bricks. Each brick can be one of 40 brick types ("colours") ( --> 6 bits) and has either a hit or PowerUp-attribute ( --> 3 bits).

 

The plain structure for the 40 levels requires about 40 kb, for saving space on the MemoryTrack this structure is packed to hold just the necessary bits but still requires about 16 kb, for saving on the NVRAM of the cartridge i am running an ICE-packer over this (cause i do already use the familiar ICE-depacker in the project for several other purposes).

 

The space available for the Level-data on the NVRAM (the serial Eeprom) is just about 1300 bytes.

 

Kind regards

Matthias

  • Like 1
Link to comment
Share on other sites

Hi!

 

The CD version of Impulse X can handle up to 4 level sets, each level set consists of 40 levels/playfields, and you can switch between the available sets via the OPTION menu:

 

1) The so called standard level set.

2) The level set with the playfields that the user created.

3) The so called 1st AddOn level set and

4) the so called 2nd AddOn level set.

 

While 2) also works without having a MemoryTrack (to some degree), for 3) and 4) a MemoryTrack is mandatory.

 

So the previously mentioned Impulse X AddOn CDs are just used to store one of these AddOn level sets on the MemoryTrack.

 

My idea is, that the levels of the AddOn level sets could/should come from the Impulse X fans, but if necessary, i can i also sit down and draw some basic brick walls to fill the gap(s).

 

Kind regards

Matthias

  • Like 1
Link to comment
Share on other sites

There are 40 playfields, each playfield consists of a grid of 18 rows with 20 columns of bricks. Each brick can be one of 40 brick types ("colours") ( --> 6 bits) and has either a hit or PowerUp-attribute ( --> 3 bits).

 

The plain structure for the 40 levels requires about 40 kb, for saving space on the MemoryTrack this structure is packed to hold just the necessary bits but still requires about 16 kb, for saving on the NVRAM of the cartridge i am running an ICE-packer over this (cause i do already use the familiar ICE-depacker in the project for several other purposes).

 

The space available for the Level-data on the NVRAM (the serial Eeprom) is just about 1300 bytes.

 

 

Just been pondering this whilst waiting for some more boring stuff to complete at work..

 

I wonder if having the data source in a less dense manner prior to compression may actually optimise the compression?

 

I am not 100% but if Ice Packer uses a Huffman algorhym could ensuring the values used to represent the level are all within a fairly small range increase the compression? Perhaps just the arrangement of the data (switch from say Colour,Power up per element to a map of just colours and a seperate map of just power-up's ?)

 

Hope that makes sense :) and more so, hope it can improve things.

  • Like 1
Link to comment
Share on other sites

 

 

Just been pondering this whilst waiting for some more boring stuff to complete at work..

 

I wonder if having the data source in a less dense manner prior to compression may actually optimise the compression?

 

I am not 100% but if Ice Packer uses a Huffman algorhym could ensuring the values used to represent the level are all within a fairly small range increase the compression?

 

More a code is present, more is 'code' is short. Using a small range for increasing the compression, don't make a big difference i think.

That can be a great exercise to found the greatest packing technic. Using an presetted dictionnary with an huffman perhaps ? :)

 

Thanks Linko :) to opening this way, i'm very interrested in talking about that :)

 

GT :)

Link to comment
Share on other sites

 

 

So the previously mentioned Impulse X AddOn CDs are just used to store one of these AddOn level sets on the MemoryTrack.

 

My idea is, that the levels of the AddOn level sets could/should come from the Impulse X fans, but if necessary, i can i also sit down and draw some basic brick walls to fill the gap(s).

 

Kind regards

Matthias

 

thanks Matthias, I'll look forward to seeing this!

Link to comment
Share on other sites

  • 3 weeks later...

Hello LinkoVitch,

 

I am sorry that i haven't replied immediately:

 

I wonder if having the data source in a less dense manner prior to compression may actually optimise the compression?

 

I am not 100% but if Ice Packer uses a Huffman algorhym could ensuring the values used to represent the level are all within a fairly small range increase the compression? Perhaps just the arrangement of the data (switch from say Colour,Power up per element to a map of just colours and a seperate map of just power-up's ?)

 

Hope that makes sense :) and more so, hope it can improve things.

 

All what you say sounds reasonable, and of course i already thought about re-arranging the data, but my current opinion about it is, that it is probably not worth the effort for this project to invest too much time into this for several reasons, one of them is that the ICE-file for the data of the standard level set (40 levels in the above described 40KB format) is about 7.4 KB, and i don't have hope that all described tricks could improve the compression process to get it below the 1.3 KB storage space of the serial Eeprom. As far as i have understood ICE, it builds a specific dictionary of patterns, so IMHO there is not much to gain by preparing the data in regards to the resulting archive-filesize.

 

 

Kind regards

Matthias

 

 

 

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Hello all!

 

Although i still need to optimize the E2prom-specific funtions in Impulse X, some days ago i thought i should better test if i really can put all parts (software and hardware wise) properly together and create a working ROM-image that boots on a stock Jaguar. Before i had only created 8bit-ROM-images on my own, but not ROMs for the 2-Chip-4MB-cartridges, and i did not even had a 2-Chip-PCB with sockets on it!

 

So after preparing the cartridge-software (this consists of several program parts) and adding the (proper) universal Encryption-header i equipped a PCB with capacitors and sockets, put the 93c86 serial Eeprom on it and checked that it works and then created the 2 ROM-files using Atari's ROMSPLIT. Then i used my Needham's Electronics EMP-20 burner to burn the .lo-file onto the U1-chip and the .hi-file onto the U2-chip. And everything worked!

 

Attached is a photo showing the cartridge in action, those who are familiar with the CD-version can see that the cartridge-version shows a different logo for the NVRAM-usage in that screen. :)

 

... now i just have to finish the software.

 

Kind regards

Matthias

post-2054-0-05509700-1372605477_thumb.jpg

  • Like 4
Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...