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!!
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.
- lower_rom
Set to -1 to disable or 0 to enable the lower ROM (from &0000 to &3FFF). - upper_rom
Set to -1 to disable or any upper ROM id to enable the upper ROM (from &C000 to &FFFF). - ram_bank
Set it with the MMR (http://www.grimware.org/doku.php/documentations/devices/gatearray#mmr) command you want.
; 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)
Thankyou!!
the funny thing is that i read this page, but the org command, not the write direct :picard:
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)
Quote from: Executioner on 01: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
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. :)
Quote from: TFM on 16:33, 27 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...
Incbin command works the same way?
I want to load bin files in extra memory usually..
Quote from: fgbrain on 17:13, 29 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.
org #4000
write direct -1,-1,#c4
incbin "graphics.bin"
Quote from: Executioner on 02:06, 29 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).
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 ?
Quote from: SRS on 21: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 ?
Something like this ?
Used for SDCC / Cpctelera
Bank value : 0xC4 to 0xC7 / 0xC0 is default
/*************** 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;
}
Quote from: TFM on 19:03, 30 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).
http://tj.gpa.free.fr/html/coding/cpc_ram.htm
it explains C1,C2 and C3 values also ;)
Quote from: Executioner on 22:17, 30 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! :)
Quote from: TFM on 16:53, 31 May 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.
Quote from: Executioner on 23:04, 31 May 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).
Quote from: TFM on 19:22, 01 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.
Quote from: gerald on 22:18, 01 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. :)
Quote from: TFM on 22:26, 01 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.
Quote from: arnoldemu on 09:24, 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) :)
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.
Right! :)