Jump to content
IGNORED

Status Update


SpiceWare

Recommended Posts

I've wrapped up and committed the changes to Stella for CDFJ+ support.  They'll be in the 6.7 release.

 

I've finished converting Part 3 of the CDFJ tutorial to use CDFJ+.  A major part of the conversion was to figure out routines that automatically configure the project based on these 4 symbols that are defined at the beginning of the 6507 code:
 

;===============================================================================
; Project Configuration
;----------------------------------------
;   _PC_ROM_SIZE        Size of ROM, in kilobytes
;        32              32 KB of ROM and  8 KB of RAM
;        64              64 KB of ROM and 16 KB of RAM
;       128             128 KB of ROM and 16 KB of RAM
;       256             256 KB of ROM and 32 KB of RAM
;       512             512 KB of ROM and 32 KB of RAM
;
;   _PC_DD_SIZE         Size of Display Data, in bytes
;       4096
;
;   _PC_CDFJ_FF         Select CDFJ+ driver based on Fast Fetcher usage:
;       FF_LDA          LDA # only
;       FF_LDA_LDX      LDA # and LDX #
;       FF_LDA_LDY      LDA # and LDY #
;       FF_LDA_LDX_LDY  LDA #, LDX #, and LDY #
;
;   _PC_FF_OFFSET       offset for Fast Fetchers
;       0 - 220         adjusts which LDA # values are overridden for fast
;                       fetcher use (and optionally LDX # and/or LDY #)
;
;===============================================================================

_PC_ROM_SIZE    = 32
_PC_DD_SIZE     = 4096
_PC_CDFJ_FF     = FF_LDA
_PC_FF_OFFSET   = $80

 

If you're building a 32K project and decide to make it 64K, all you need to do is change _PC_ROM_SIZE to 64. The proper driver will then be included (as 64K and up uses a different chipset), the RAM allocation will become 16K, and the C code will adjust accordingly (such as 8K of additional C Variable space).

 

If you're running out of C Variable space and have unused space in Display Data, just decrease the size of _PC_DD_SIZE.  If you're using a larger ROM with more RAM you can even increase Display Data size as CDFJ+ no longer limits Display Data to 4K. In both cases the C Variable space will adjust accordingly.

 

My next step is to review the project, such as this section of code:

MenuKernel:
        sta WSYNC
        FFSTA _DS_MENU_P0, GRP0
        FFSTA _DS_MENU_P1, GRP1
        dey
        bne MenuKernel

 

which needs comments added to explain what's going on with the new FFSTA macros.

 

I'm also going to review the comments and corrections in the CDFJ tutorial, such as reply 3 and reply 14 by @Dionoid in Part 5 - Source Improvements and implement them in Part 3 of the CDFJ+ tutorial.

 

Have family in town for the weekend, so Part 3 will most likely be posted next weekend.

  • Like 3
Link to comment
Share on other sites

Sorry, but the next update will be at least another week.  Found out last night that friends from Mexico will be in town for the weekend.

 

We're also working on getting the build process to work under Linux, Mac, and Windows! While I've been using a Virtual Machine running Linux to compile the ARM code, @Andrew Davie and @johnnywc have been using native tools under MacOS and Windows.

 

If we get this working then you will not need to use a virtual machine like I've had to over the years (the ARM compiler was not available for Mac when I started).

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Going to be a little bit longer:

 

Part of the team is on vacation, so we've not been able to fully test the new build processes.

 

Batari spotted an issue with the driver that causes it to perform differently when run via Harmony menu vs. when flashed to a Melody board. This could cause a game that runs OK during testing to have screen jitter/rolls when released on stand-alone cartridges.

Link to comment
Share on other sites

On 3/4/2022 at 8:12 AM, SpiceWare said:

We're also working on getting the build process to work under Linux, Mac, and Windows! While I've been using a Virtual Machine running Linux to compile the ARM code, @Andrew Davie and @johnnywc have been using native tools under MacOS and Windows.

 

If we get this working then you will not need to use a virtual machine like I've had to over the years (the ARM compiler was not available for Mac when I started).

 

Mac: I installed the arm-none-eabi-gcc package from macports then built and ran your CDFJ Collect3 program without any problems. (Likely using some other stuff I already had installed.)

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...
  • Recently Browsing   0 members

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