writing to cart port (not IO space) on 64

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

writing to cart port (not IO space) on 64

Jim Brain

I know ROML and ROMH are only active on reads, except in Ultimax mode. 

My question is:

Can anyone help with a small function that would take an address, a data value, a flag for the ROM area to write, and handle the heavy lifting of:

  • switching to Ultimax mode
  • doing the write
  • switching out of Ultimax mode
I know EasyFlash does this, but the programmer utility is a huge piece of code, and I'd like to get a better understanding of how this works.  I also am unclear on why the EF has RAM mapped into IO, as Ultimax mode seems to still offer 4kB of RAM at $0-$fff

Jim

-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: writing to cart port (not IO space) on 64

Daniel Kahlin-2
On Thu, 23 Feb 2017, Jim Brain wrote:

> I know ROML and ROMH are only active on reads, except in Ultimax mode.
>
> My question is:
>
> Can anyone help with a small function that would take an address, a data
> value, a flag for the ROM area to write, and handle the heavy lifting
of:
>
> * switching to Ultimax mode
> * doing the write
> * switching out of Ultimax mode

You cannot switch to Ultimax mode purely by software.  The cartridge needs
to provide some way to fiddle with EXROM & GAME.

Trivial example for Action Replay/Retro Replay:

MODE_BITS       equ     %00100011       ; RAM + Ultimax
BANK0_BITS      equ     %00000000
BANK1_BITS      equ     %00001000
BANK2_BITS      equ     %00010000
BANK3_BITS      equ     %00011000
BANK4_BITS      equ     %10000000
BANK5_BITS      equ     %10001000
BANK6_BITS      equ     %10010000
BANK7_BITS      equ     %10011000

; Acc = data, Y = bank (0-7)
write byte:
         sei

; optional to avoid visible glitches, wait until border area
         ldx     #$30
lp:
         cpx     $d012
         bcc     lp

; perform write
         ldx     bank_bits_tab,y
         stx     $de00           ; enable ultimax (in RAM $0000-$0fff)
         sta     $1234           ; <---- poke address here
         ldx     #%00000000      ; (this is for returning to ROM,
                                 ; change to what you need.)
         stx     $de00           ; restore normal operation
         rts

bank_bits_tab:
         dc.b    BANK0_BITS | MODE_BITS
         dc.b    BANK1_BITS | MODE_BITS
         dc.b    BANK2_BITS | MODE_BITS
         dc.b    BANK3_BITS | MODE_BITS
         dc.b    BANK4_BITS | MODE_BITS
         dc.b    BANK5_BITS | MODE_BITS
         dc.b    BANK6_BITS | MODE_BITS
         dc.b    BANK7_BITS | MODE_BITS

/Daniel

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: writing to cart port (not IO space) on 64

Jim Brain
On 2/24/2017 1:04 AM, Daniel Kahlin wrote:

> On Thu, 23 Feb 2017, Jim Brain wrote:
>
>> I know ROML and ROMH are only active on reads, except in Ultimax mode.
>>
>> My question is:
>>
>> Can anyone help with a small function that would take an address, a data
>> value, a flag for the ROM area to write, and handle the heavy lifting
> of:
>>
>> * switching to Ultimax mode
>> * doing the write
>> * switching out of Ultimax mode
>
> You cannot switch to Ultimax mode purely by software.  The cartridge
> needs
> to provide some way to fiddle with EXROM & GAME.
Understood.  I forgot to mention that in my original post.

>
> Trivial example for Action Replay/Retro Replay:
>
> MODE_BITS       equ     %00100011       ; RAM + Ultimax
> BANK0_BITS      equ     %00000000
> BANK1_BITS      equ     %00001000
> BANK2_BITS      equ     %00010000
> BANK3_BITS      equ     %00011000
> BANK4_BITS      equ     %10000000
> BANK5_BITS      equ     %10001000
> BANK6_BITS      equ     %10010000
> BANK7_BITS      equ     %10011000
>
> ; Acc = data, Y = bank (0-7)
> write byte:
>         sei
>
> ; optional to avoid visible glitches, wait until border area
>         ldx     #$30
> lp:
>         cpx     $d012
>         bcc     lp
OK, I partially understand this.  Is it because color ROM is no longer
wired to anything?  Because, I assume you could relo the screen RAM to
somewhere in the first 4kB

Jim

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: writing to cart port (not IO space) on 64

Daniel Kahlin-2


On Fri, 24 Feb 2017, Jim Brain wrote:

>> ; optional to avoid visible glitches, wait until border area
>>         ldx     #$30
>> lp:
>>         cpx     $d012
>>         bcc     lp
> OK, I partially understand this.  Is it because color ROM is no longer wired
> to anything?  Because, I assume you could relo the screen RAM to somewhere in
> the first 4kB

It's because the character ROM is not visible to the VIC-II in ultimax
mode.

I suppose you could put the charset in RAM and have full speed writing
with the screen visible.

/Daniel


       Message was sent through the cbm-hackers mailing list
smf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: writing to cart port (not IO space) on 64

smf
On 25/02/2017 18:08, Daniel Kahlin wrote:
> I suppose you could put the charset in RAM and have full speed writing
> with the screen visible.

You don't even need a full 2k character set, you only need the
characters you want.

Which can even be overlaid with the screen matrix, if you set the
foreground color to the same as the background colour in the areas that
include the font.

With 5 characters per screen line, you can sacrifice 9 lines and get 45
characters & there is space for another three in the 24 bytes after the
screen.


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: writing to cart port (not IO space) on 64

Jim Brain
In reply to this post by Daniel Kahlin-2
On 2/25/2017 12:08 PM, Daniel Kahlin wrote:


On Fri, 24 Feb 2017, Jim Brain wrote:

; optional to avoid visible glitches, wait until border area
        ldx     #$30
lp:
        cpx     $d012
        bcc     lp
OK, I partially understand this.  Is it because color ROM is no longer wired to anything?  Because, I assume you could relo the screen RAM to somewhere in the first 4kB

It's because the character ROM is not visible to the VIC-II in ultimax mode.

I suppose you could put the charset in RAM and have full speed writing with the screen visible.

/Daniel


      Message was sent through the cbm-hackers mailing list

OK, understood.  So, why does AR and EF have RAM in the IO space?  Is it because RAM is so limited when in Ultimax mode?

Jim


-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: writing to cart port (not IO space) on 64

Michał Pleban
Hello!

Jim Brain wrote:

> OK, understood.  So, why does AR and EF have RAM in the IO space?  Is it
> because RAM is so limited when in Ultimax mode?

I would rather assume that freezer cartridges such as AR have additional
RAM so that they do not overwrite the computer memory with their own
data when freezing.

Regards,
Michau.


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: writing to cart port (not IO space) on 64

Groepaz
On Sunday 26 February 2017, 22:05:46 Michał Pleban <[hidden email]> wrote:
> Hello!
>
> Jim Brain wrote:
> > OK, understood.  So, why does AR and EF have RAM in the IO space?  Is it
> > because RAM is so limited when in Ultimax mode?
>
> I would rather assume that freezer cartridges such as AR have additional
> RAM so that they do not overwrite the computer memory with their own
> data when freezing.

exactly. and its good to have space for "trampoline" functions in i/o space.

--

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ar.pokefinder.org

In headlines today, the dreaded killfile virus spread across the country
adding 'aol.com' to people's Usenet kill files everywhere. The programmer of
the virus still remains anonymous, but has been nominated several times for a
Nobel peace prize.
<Mark Atkinson>



       Message was sent through the cbm-hackers mailing list
Loading...