CPCWiki forum

General Category => Emulators => Topic started by: Joseman on 23:12, 24 May 16

Title: Compiling on winape - second bank
Post by: Joseman on 23:12, 24 May 16
Hi

Anyone knows if in winape i can compile some code directly on the second bank of memory, for example on configuration #C2 in #C000

something like this:

org #C2-#C000

Thankyou!!

Title: Re: Compiling on winape - second bank
Post by: SRS on 23:29, 24 May 16
Maybe like this:

   Syntax:WRITE DIRECT [<lower_rom>[,<upper_rom>[,<ram_bank>]]]  The WRITE DIRECT allow you to compile your code into the emulator memory. By default, the base 64Kb RAM is selected but you can select anything else with the optionnals parameters.
       
; Compile a routine directly in bank 0 of page 0 WRITE DIRECT -1,-1,&C4 ORG &4000 LD HL,&C000 LD DE,&C001 LD BC,&3FFF LD (HL),L LDIR RET

documentations:software:winape:start [Grimware] (http://www.grimware.org/doku.php/documentations/software/winape/start)

Title: Re: Compiling on winape - second bank
Post by: Joseman on 23:04, 25 May 16
Thankyou!!

the funny thing is that i read this page, but the org command, not the write direct  :picard:
Title: Re: Compiling on winape - second bank
Post by: Executioner on 03:54, 27 May 16
The included WinAPE help file has been updated to include all this information, and is also available online:

WinAPE Assembler Directives (http://www.winape.net/help/assembler_directives.html)
Title: Re: Compiling on winape - second bank
Post by: TFM on 18:33, 27 May 16
The included WinAPE help file has been updated to include all this information, and is also available online:

WinAPE Assembler Directives

It tells.... "and ram_bank can be an expansion bank number #C0 to #FF (or #8C0 to #EFF for Yarek 4MB style bank mapping)."

However I would suggest to write "and ram_bank can be an expansion bank number #C0 to #FF (or #8C4 to #EFF for Yarek 4MB style bank mapping)."


Reason: &C0 is always the same. First expansion RAM block (16K) of a 512 KB bank is always C4. :)
Title: Re: Compiling on winape - second bank
Post by: Executioner on 04:06, 29 May 16
Reason: &C0 is always the same. First expansion RAM block (16K) of a 512 KB bank is always C4. :)

Technically, it's #8C1, but #8C0 is a valid bank, even though it's the same as #C0, #C8, #D0, #D8 etc...
Title: Re: Compiling on winape - second bank
Post by: fgbrain on 19:13, 29 May 16
Incbin   command  works the same way?

I want to load bin files in extra memory usually..
Title: Re: Compiling on winape - second bank
Post by: Executioner on 00:55, 30 May 16
Incbin   command  works the same way?

I want to load bin files in extra memory usually..

Yes, if you put the write direct before the incbin, eg.

Code: [Select]
org #4000
write direct -1,-1,#c4
incbin "graphics.bin"
Title: Re: Compiling on winape - second bank
Post by: TFM on 21:03, 30 May 16
Technically, it's #8C1, but #8C0 is a valid bank, even though it's the same as #C0, #C8, #D0, #D8 etc...


C0 ist misleading, I just tried to help. (16 KB block banking seems to be the underlying scheme, so special configurations could be disregarded).
Title: Re: Compiling on winape - second bank
Post by: SRS on 23:15, 30 May 16
Do we have a small tutorial here how to use the extra ram ? I'd use it for maybe storing level data ... c sources anywhere ?
Title: Re: Compiling on winape - second bank
Post by: Arnaud on 23:32, 30 May 16
Do we have a small tutorial here how to use the extra ram ? I'd use it for maybe storing level data ... c sources anywhere ?

Something like this ?
Used for SDCC / Cpctelera
Bank value : 0xC4 to 0xC7 / 0xC0 is default

Code: [Select]
/*************** Select Bank memory ******************/
u8 SetBank(u8 pBank)
{
    u8 oldBank = 0xC0;
    if (_bank != pBank)
    {   
        oldBank = _bank;
        _bank = pBank;
        __asm
         
        PUSH IX    ; Save IX before making changes
        LD IX, #0  ; IX points to the top of the stack:
        ADD IX, SP ;  1st parameter is IX+4, as we have IX (2 bytes) + Return Address (2 bytes) in the stack
         
        LD bc, #0x7C00   
        OUT (c), c   
        LD a, 4(ix)
        OUT (c),a

        POP IX       ; Restore IX before returning
         
        __endasm;
    }
   
    return oldBank;
}
Title: Re: Compiling on winape - second bank
Post by: Executioner on 00:17, 31 May 16

C0 ist misleading, I just tried to help. (16 KB block banking seems to be the underlying scheme, so special configurations could be disregarded).

Yes, but #C0 etc might be required if you want to switch back later in the code. All banks work, including #C1, #C2 and #C3 etc. So it's possible to write code which runs in bank #C2 for example without splitting code or messing around with org values. It's also useful to support all valid values so that you can use them in macros and loops for example (I did this to pre-load a wav file into 4Mb of RAM using incbin with an offset, for example).
Title: Re: Compiling on winape - second bank
Post by: roudoudou on 12:16, 31 May 16
http://tj.gpa.free.fr/html/coding/cpc_ram.htm

it explains C1,C2 and C3 values also ;)
Title: Re: Compiling on winape - second bank
Post by: TFM on 18:53, 31 May 16
Yes, but #C0 etc might be required if you want to switch back later in the code. All banks work, including #C1, #C2 and #C3 etc. So it's possible to write code which runs in bank #C2 for example without splitting code or messing around with org values. It's also useful to support all valid values so that you can use them in macros and loops for example (I did this to pre-load a wav file into 4Mb of RAM using incbin with an offset, for example).


That's pretty awesome!  :)
Title: Re: Compiling on winape - second bank
Post by: Executioner on 01:04, 01 June 16
That's pretty awesome!  :)

In 4MB you can get a complete 8kHz mono song for digiblaster, up to about 9 minutes. I was wondering if interleaving IDE I/O with digiblaster writes may be possible, but on a real IDE implementation (ie. Symbiface, CPC-IDE, X-MASS) there would probably be delays between sector reads.
Title: Re: Compiling on winape - second bank
Post by: TFM on 21:22, 01 June 16
In 4MB you can get a complete 8kHz mono song for digiblaster, up to about 9 minutes. I was wondering if interleaving IDE I/O with digiblaster writes may be possible, but on a real IDE implementation (ie. Symbiface, CPC-IDE, X-MASS) there would probably be delays between sector reads.


On a real IDE (which should be so fast that the CPC will not need to wait) I would suggest somthing like this.

- Send command to read sector

- OUT a byte for digiblaster
- Read a byte from IDE

- Repeat two last commands for 512 time

- Go to start.


(I did this with Dobbertin HD20 and it already works well, since the device (as IDE) buffers a sector and you can read the bytes when ever you want. However in case of the HD20 the timing must be a bit more precise. But I can confirm it working).
Title: Re: Compiling on winape - second bank
Post by: gerald on 00:18, 02 June 16
On a real IDE (which should be so fast that the CPC will not need to wait).
Not sure about that.
Access time on a HD is function of its RPM and is in the order of 7ms for a 10k RPM HD, 12ms for a 5.6K RPM HD.
So at least your 1st access will have to wait for the head to seek to the proper track and then wait for the sector.
Next, you will have to request multiple sectors to be sure the HD read them ahead of your need, but this is limited to 256 sectors.
Finally, if of your file is fragmented, count one more access time for each fragment.

You may leverage that by using a local buffer, at least big enough to cover the access time.
Title: Re: Compiling on winape - second bank
Post by: TFM on 00:26, 02 June 16
Not sure about that.
Access time on a HD is function of its RPM and is in the order of 7ms for a 10k RPM HD, 12ms for a 5.6K RPM HD.
So at least your 1st access will have to wait for the head to seek to the proper track and then wait for the sector.
Next, you will have to request multiple sectors to be sure the HD read them ahead of your need, but this is limited to 256 sectors.
Finally, if of your file is fragmented, count one more access time for each fragment.

That's right. For the first sector you have to wait minor time. Then the IDE device will - as you told - read ahead. So, as soon one sector (512 bytes) have been written, it's important to immediately tell the IDE: "read next sector". That does work fine.  :)

You do in addition mention an very important point: Fragmentation can be a problem here. So keep the disc defragmented. That's not a problem, because one has to write the data in one block only once, then don't touch the file. But yes, too much file-copy and so on will screw it up. What I do to defragment (in this case it was the HD20) is to copy every thing to one partition, then delete source files, then copy em all back. Be sure you have them all backed up before.  :)


As buffer I did use one segment of 512 bytes, worked well.  :)
Title: Re: Compiling on winape - second bank
Post by: arnoldemu on 11:24, 02 June 16
That's right. For the first sector you have to wait minor time. Then the IDE device will - as you told - read ahead. So, as soon one sector (512 bytes) have been written, it's important to immediately tell the IDE: "read next sector". That does work fine.  :)
All IDE's and probably the HD20 also support multi sector read and write. So it's possible to tell it to read up to 256 sectors at a time. I don't know what the size of the internal buffer is on either device, so there will be a small delay between each probably.

Title: Re: Compiling on winape - second bank
Post by: TFM on 18:48, 02 June 16
All IDE's and probably the HD20 also support multi sector read and write. So it's possible to tell it to read up to 256 sectors at a time. I don't know what the size of the internal buffer is on either device, so there will be a small delay between each probably.


Never saw a delay in reality, the devices are small enough (talking IDE now)  :)
Title: Re: Compiling on winape - second bank
Post by: Executioner on 09:45, 03 June 16
If you get fragmentation, you can't simply read ahead, but you have to specify each sector as you go. Reading the sector data itself is much quicker per byte than the current 8KhZ digiblaster loop (125us per byte), so in theory you've got time to send the sector read command between every digiblaster output, and there's only 8 bytes required per millisecond. You should have enough read-ahead to allow the drive to do full end to end seeks.
Title: Re: Compiling on winape - second bank
Post by: TFM on 18:21, 03 June 16
Right!  :)