Jump to content
IGNORED

Putting 22kb of char data into a 64kb machine?


Recommended Posts

By char data do you just mean 22K of Data or is the Data character sets.

If the former, unless there's a need to have it on some sort of boundary, anywhere that's convenient,

maybe some under the OS ROM if your code will allow that.

If character sets, the only limitation is each set must start on a 1K boundary, but they could be scattered

anywhere in 1K blocks

 

Again, does the data need to be contiguous ?

Does your program need a DOS ? extra space there if not used.

  • Like 1
Link to comment
Share on other sites

11 minutes ago, TGB1718 said:

By char data do you just mean 22K of Data or is the Data character sets.

If the former, unless there's a need to have it on some sort of boundary, anywhere that's convenient,

maybe some under the OS ROM if your code will allow that.

If character sets, the only limitation is each set must start on a 1K boundary, but they could be scattered

anywhere in 1K blocks

 

Again, does the data need to be contiguous ?

Does your program need a DOS ? extra space there if not used.

Thanks for the quick answers, mate... :)

 

It's actually 22 charsets that I need to put somewhere. Continuous would be comfortable of course, but I guess I could find a workaround for that...

 

Then, how much KBs would be theoretically left after that for other things like sprites and music data, game code, etc?

 

Link to comment
Share on other sites

Do you need them all in one go or could they be brought in when needed, e.g. are they levels, can you use a bank switched cartridge?
I ask as screen memory is either made of character values and so each bringing in the data for the 8x8 mono or 4x8 multi-color char image, and so screen memory is small, e.g. 40x24 =  960 bytes, ~1KB

Or is the character data being copied to a bitmap screen of 320 mono pixel or 160 4-color pixels by 192, so 40x192 = 7680 bytes, ~8KB

 

For a 48K game you typically can use $400->$BFFF and so 22KB is $5800 so $C000-$4000-$5800 leaves $6400 = 25KB.
Utilising memory under the OS can give you another $3800 = 14KB so that would be 29KB in total minus the 1KB or 8KB used by the screen.

 

So going back to my first question, are all fonts being used on the screen (for example by using display list changes) such that they are all needed to be in RAM?

If not then they could probably be compressed and only those needed for what you are doing decompressed when needed, saving you some space at the expense of time.

 

  • Like 1
Link to comment
Share on other sites

You could put some of your code under the OS, obviously you would need careful programming to switch  the ROM in/out

as required.

 

I took this from BASICXE manual as it shows the available areas. Only $D000 to $DFFF are unusable (4K)

 

image.thumb.png.de045998df399e98a337a016b08e1cdf.png

  • Like 1
Link to comment
Share on other sites

At most you only see part of the charset at a time, is it possible to have e.g. half on line 1, other half line 2 to save memory?

 

Given the scenario you present, you'd need 22K of memory easily accessable.

Though in theory with DLIs you could do bankswitching at the appropriate times.

The only need for the OS part way down the screen is usually to just process keyboard IRQ (aside from need of the default charset which you're not needing here)

You could mask IRQs and have the Ram under OS presented e.g. for 14 text lines, then just unmask the IRQ once the banking is back to OS Rom in.  Any KB IRQ would just get delayed a little.

Edited by Rybags
Link to comment
Share on other sites

Take any continuous part of ram imho.

Turn of Os if leftover space is not enough. Ignore trying to preserve "important memory locations not supposed to be touched" :)
Be a rebel! Use every possible byte to make 22 charsets work ! Make something unique...

Then... When it's working and people are amazed - then and only then try to optimize, make it more compatible or whatever... Until then just take space from where you can :)

 

  • Like 3
Link to comment
Share on other sites

2 hours ago, popmilo said:

Take any continuous part of ram imho.

Turn of Os if leftover space is not enough. Ignore trying to preserve "important memory locations not supposed to be touched" :)
Be a rebel! Use every possible byte to make 22 charsets work ! Make something unique...

Then... When it's working and people are amazed - then and only then try to optimize, make it more compatible or whatever... Until then just take space from where you can :)

 

Totally opposite to the approach I took working on Popeye ;) But not that my way was a walk in the park either.

 

A suggestion to the OP though, one character set is worth of having 3 lines of text without repeating characters, so 8 charsets to have a full screen of unique characters, and this does not account for the extra color / inverse going with the 8th bit. This if course all depends on the actual effect you want to achieve, animations, etc. But, what I am getting at, when I did charsets for my game I actually wrote Python scripts to help me with the work and optimize some things out. If you are doing them all by hand there might be some memory waste coming out of this too ;)

  • Like 1
Link to comment
Share on other sites

18 hours ago, Wrathchild said:

@Steril707 needs to be a clearer about what they are trying to achieve

My feeling is it could be something like @popmilo experimented with when working on Wonderboy's level scrolling using a font per line.

 

I have this running with 11 charsets (one per line), using Antic5:

https://content.invisioncic.com/r322239/monthly_2023_12/Dragonwood.mp4.b914d1be79dd43c071728636b38fb6eb.mp4

 

Somehow it itches me to get Antic4 running with this... ;)

 

That's why I ask..

 

  • Like 1
Link to comment
Share on other sites

5 hours ago, Steril707 said:

 

I have this running with 11 charsets (one per line), using Antic5:

https://content.invisioncic.com/r322239/monthly_2023_12/Dragonwood.mp4.b914d1be79dd43c071728636b38fb6eb.mp4

 

Somehow it itches me to get Antic4 running with this... ;)

 

That's why I ask..

 

That looks really neat but from a technical standpoint, may I ask why this requires (or perhaps not requires, but it using) one font per line?  I've never done coding before where I draw into a character set to simulate a bitmap screen so apologies if I am missing something obvious.

Link to comment
Share on other sites

2 hours ago, Irgendwer said:

So where is the restriction when using one font on three character lines?

Well you only have 8 chars left for "something else" per 3 char rows.
With charset per char row, you have like 88 free chars per char row.

For me 22 charsets is little too much :)
That's why I've used 4 charsets which was gave me nice ratio of memory taken and free chars for soft sprites.
 

Edited by popmilo
Link to comment
Share on other sites

What if the level is like 1024 chars long, and you want to have a lot of variety, and in that context different chars on each line going through the level?

And yes, having enough chars left for soft sprites would be a bonus.

 

Maybe, coming from the Amiga and Neo Geo, my idea of scrolling is completely different on what you guys normally do on the A8s, though... :D

 

 

  • Like 1
Link to comment
Share on other sites

We're talking a machine with under 1/4 the speed, no blitter and a fraction of the memory.

Compromises have to be made.

With many h-scrolling games, there's similar fixed shapes usually at top, middle and bottom regions which might help.

 

A character set doesn't have to be set in stone. 

You could have a sparse screen where character set swaps could occur.

You could have the playfield character data brought in on the fly.

  • Like 2
Link to comment
Share on other sites

.

8 minutes ago, Steril707 said:

Only RAM.

...and that's why I asked.

To have a black background available in all 22 fonts you spend already more than a half page of RAM only for that without benefit for variety.

Even if you level is 1024 chars wide you could use a much more conservative approach for font usage and only copy those representations to the char data you actually need for the section of the screen.

Thoughtful planning of the resources is needed though.

Link to comment
Share on other sites

Still, if he pulls off what he attempting, then slowly compacts things down until it works as intended, he might do something quite nice and pick a new sweet spot for a balance we've not seen. Most people haven't attempted this in the way he has, it might turn out to be something good and find an overlooked avenue to get some unexpected result. Either way valuable knowledge is imparted, success or not.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

With all respect, guys.

I was just asking for a technical info here. Which I got the answer for a few posts in.

 

I am completely accepting that you guys have a different view on how to handle this, but in the end that won't change my approach to this little experiment here.

 

add/edit: Thanks @ The Doctor :)

Edited by Steril707
  • Like 3
Link to comment
Share on other sites

As @Rybags said, you could have char data "brought in on the fly".

In my experiments I did virtual charset thing with like a thousand different chars in "charset" for a huge level map (think 25x4 screens for example).

I wrote python script to process map and write data for where which new char is supposed to be inserted into visible charsets as you scroll screen to the right.

In the end number of updated chars per frame was like zero to four, five max.
Of course I needed different kind of tilemap, and all those chars needed to be in ram, so I would say each approach takes it's own resources.

Just do it you're own way :)
I would sure like to see results :)

 

  • Like 2
Link to comment
Share on other sites

7 hours ago, popmilo said:

As @Rybags said, you could have char data "brought in on the fly".

In my experiments I did virtual charset thing with like a thousand different chars in "charset" for a huge level map (think 25x4 screens for example).

I wrote python script to process map and write data for where which new char is supposed to be inserted into visible charsets as you scroll screen to the right.

In the end number of updated chars per frame was like zero to four, five max.
Of course I needed different kind of tilemap, and all those chars needed to be in ram, so I would say each approach takes it's own resources.

Just do it you're own way :)
I would sure like to see results :)

 

That's a very interesting idea, though.

Thanks for that, @popmilo ..

  • Like 1
Link to comment
Share on other sites

  • 1 month later...
Posted (edited)
On 2/11/2024 at 10:48 PM, popmilo said:

As @Rybags said, you could have char data "brought in on the fly".

In my experiments I did virtual charset thing with like a thousand different chars in "charset" for a huge level map (think 25x4 screens for example).

I wrote python script to process map and write data for where which new char is supposed to be inserted into visible charsets as you scroll screen to the right.

In the end number of updated chars per frame was like zero to four, five max.
Of course I needed different kind of tilemap, and all those chars needed to be in ram, so I would say each approach takes it's own resources.

Just do it you're own way :)
I would sure like to see results :)

 

Hello @popmilo, can you elaborate a bit on this? :)
I was thinking about how to do this thing in another way lately, and your approach sounds interesting.

Do I have to imagine this like some kind of "char sequencer" that counts down when to copy data from the char ram to the charsets?

 

That would work only linearly into one direction though, wouldn't it?

 

Happy for any thoughts, of course also by anybody else... ;)

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

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