Jump to content
IGNORED

Changing cart access and directory in my version of cc65


karri

Recommended Posts

I realized that the very crude cc65 cart libs are getting too crude for my needs. Due to Wizzy I plan to make two changes.

 

The old directory had 8 bytes per file allocated. I plan to ditch the filetype byte and make the _FileStartBlock 16 bit (it used to be just 1 byte).

 

; ------------------------------------------------------------------------
; Filesystem variables needed for reading stuff from the Lynx cart
_FileEntry:                     ; The file directory entry is 8 bytes
_FileStartBlock:    .res   2
_FileBlockOffset:   .res   2
_FileDestAddr:      .res   2
_FileFileLen:       .res   2

 

The lowest bits of the block counter are as before. But the higher bits are like A19 (CART0,CART1) and A20 (AUDIN). This layout is compatible with emulators already
Using separate cart strobes also means that you don't need to tackle the dual boot problem intruduced by AUDIN addressing. So you should be good to go up to 1MB.

 

This will also affect open(), lseek() and read() functions.

 

I also have a need to pick out digital data from a matrix stored on the cart. So it would be handy to finally implement SEEK_CUR in addition to SEEK_SET.
The SEEK_SET is currently setting the pointer anywhere on the cart. Files are implemented only on the directory level.

 

The SEEK_CUR would always use skip bytes if the desired position is in the current block. If this is not possible it would fallback to the SEEK_SET method.

 

Before someone comments on why I don't implement the FILE * pointer. Good question. But the Lynx only has one block counter. So running two files in parallell does not work.

 

For wizzy I am prototyping a spatial database that allows me to pick map items close to my current location with minimal delays. Currently a cell is 64x64 pixels.

 

I know that these changes will be breaking compatibility with the main release of cc65. But perhaps these changes are desired to port over at some point in time.

 

  • Like 1
Link to comment
Share on other sites

Now I have implemented SEEK_CUR. It was a bit trickier than I thought. For practical use I do something like:

 

        offset = (startxtile() / 4) * 16;
        offset += (startytile() / 4) * 4 * 64;
        openn((int)&AREA000_FILENR);
        lseek(0, offset, SEEK_CUR);

The open() method sets the pointer to where the file is on the cart.
FileStartBlock
FileBlockOffset

As there are other things messing around with the hardware I decided to use the directory record as a reference instead of trying to restrict the use of the address counter.

 

The lseek() method sets the hardware as an offset to the start of the file. So consecutive calls to SEEK_CUR will not advance the pointer.

 

If you want to just skip bytes it is better to do dummy reads as it won't unnecessary zero the address counter.

 

I may create a more complex version later that won't reset the address counter. But for now I go with this.

 

static void lseekrelative(unsigned char count)
{
        unsigned char buf[16];
        unsigned char i;
        for (i = 0; i < count; i++) {
                read(0, buf, 16);
        }
}

My records happen to be 16 bytes. Or actually 16 indices to a tile map. This scrolls at a tolerable speed with 1024 byte blocks. The 2048 bytes per block is worse. But there is not much I can do to speed it up. Perhaps building up the scenery in a separate bg thread? Then the movement is fluid but the tiles appear later.

 

Like this. Outlined 4 records:

example.png.6e72735ba40b759477a1b2c89e3995af.png

 

  • Like 1
Link to comment
Share on other sites

4 hours ago, 42bs said:

Can't you pre-load the next tiles?

Yes! But there is still a limit of how much stuff I want to have in memory. But I found out that I had a bug in my code that fetched 4 times too often tiles from the cart. Now I am happy with my code even when using 2k blocks.

 

Currently my biggest problems are improving on the visuals and creating good sounds for the actions.

 

I also found out that the play area works without annoying delays without any size limitations. The restricting factor is how much I have energy to draw new scenarios.

 

I would like the player to spend considerable time in all 6 worlds of the game. Hopefully there is not too much tedious grinding in the game. But for the skilled players you can get epic stuff making your player stronger.

 

Just the world graphics will be around 600k.

 

PS. I just received my Wizzy carts. After some basic testing I send one your way.
 

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