Posts: 97
Threads: 23
Joined: Jul 2011
Reputation:
0
Hi all
I'm testing and expanding this code (without the CLEAR command) from a post from speccy.org forum in order to test memory bank paging:
Code: 10 CLEAR 49151
20 POKE 23388,16: OUT 32765,16: POKE 50000,1
30 POKE 23388,17: OUT 32765,17: POKE 50000,2
40 POKE 23388,19: OUT 32765,19: POKE 50000,3
50 POKE 23388,20: OUT 32765,20: POKE 50000,4
60 POKE 23388,22: OUT 32765,22: POKE 50000,5
70 POKE 23388,16: OUT 32765,16: PRINT PEEK 50000
75 POKE 23388,17: OUT 32765,17: PRINT PEEK 50000
80 POKE 23388,19: OUT 32765,19: PRINT PEEK 50000
85 POKE 23388,20: OUT 32765,20: PRINT PEEK 50000
90 POKE 23388,22: OUT 32765,22: PRINT PEEK 50000
Poking&Peeking memory addresses are working ok, but I'd like to know is there is a way to "put" zxbasic code in the memory bank I want to and, if yes, how I can achieve it.
Thanks and regards
Posts: 806
Threads: 135
Joined: Apr 2009
Reputation:
5
I think the problem is the compiler has no concept of memory banks.
You can force the page swapping around - you could even compile code inside this zone, but the jumps would all be local. If the compiler was aware of bank switching, it could be taught to use a jump routine to page in the right block before jumping to code in another page.
Posts: 97
Threads: 23
Joined: Jul 2011
Reputation:
0
Thanks britlion. So, the only way to rest assure that I can use the extra banks is poking&peeking raw values. It could be nice that the compiler was aware of bank switching.
Cheers
Posts: 806
Threads: 135
Joined: Apr 2009
Reputation:
5
LCD has been looking at this.
Full support will require Boriel to code the compiler so that it understands the 128 memory structure - and I think he's far too light on time for that. It's been a very asked for feature for some years now
But have a look at <!-- l --><a class="postlink-local" href="http://www.boriel.com/forum/how-to-tutorials/megalz-depacker-t721.html#p4355">how-to-tutorials/megalz-depacker-t721.html#p4355</a><!-- l -->
Here LCD shows how you can page another block of memory in, unpack some compressed data from the other page to a buffer in lower memory. You can use this to store more levels for a game and extra data - pulling in data chunks to a working buffer as you need them.
Posts: 615
Threads: 49
Joined: Feb 2009
Reputation:
2
The present version of BorIDE can link binary files in memory banks and create fully working 128K program. I tested it already with some megaLZ packed graphics to unpack it in a bufer in low memory (for use with Britlions PutChars) or even directly to screen. It should be also possible to compile a part of your program to a bank and run it there, but unfortunaly this means that some runtimes are included twice.
Oh! Just forgot: The modified MegaLZ unpacker mentioned by britlion, works also fine with larger programs (40 Kb), if the procedure is somewhere in memory which is not paged out. And the interrupt manager allows to play music that is stored in a different memory bank, but that would bite with MegaLZ because I disabled the interrupts as they may be harmful when switching banks.
Posts: 97
Threads: 23
Joined: Jul 2011
Reputation:
0
So compiler can't work directly with memory banks but it can be done with the last BorIDE and the MegaLZ routinecan (at least as a workaround) Thanks you both, I'll will try it
Cheers
Posts: 1,790
Threads: 56
Joined: Aug 2019
Reputation:
25
That's right. As Britlion says, the fastest solution (well, workaround) is to make bank-switching funtions. I think there are bank switching functions already in the library. Other people has managed to program with them. Think like it was in BASIC with the LOAD! and SAVE! functions. However, another not so cheap solution is to use other banks for thinks like Array data, and maybe the HEAP.
For example, I imagine one can declare an array at a given BANK, like:
Code: REM Declares A at BANK 4, Address 12000 Within the bank
DIM A(5, 6) As Ubyte AT #4:12000
Or something like that, but this will require to change big areas of the compiler at the moment, not only syntax, because whenever you access an array, a bank switch must be done automatically for you, etc...
Posts: 615
Threads: 49
Joined: Feb 2009
Reputation:
2
boriel Wrote:Or something like that, but this will require to change big areas of the compiler at the moment, not only syntax, because whenever you access an array, a bank switch must be done automatically for you, etc... And this would also break the loader of BorIDE, as it generates anything from BIN output by itself. Anyway, it would be still possible to fix this.
I think, my solution which already exist, is a good way to work around the problem, and serve the compressed data which allows even to store much more of it in memory banks. I think, decompression from memory bank to Array should be possible too (if this data exists as binary file), but the Array data would still be in the main memory (I always used DEFB and no arrays).
I was successfull to store pictures worth more than 32Kb in one bank (The pictures for "Star Trek Classic", I displayed on my homepage), so storing 160 Kb using the compressor+compiled code should be possible. Sure, I need a bufer in low memory (in this case 3888 bytes), but such a bufer can be also reused for many other things, also for flickerfree animations or temporary storage of picture.
Posts: 1,790
Threads: 56
Joined: Aug 2019
Reputation:
25
LCD Wrote:boriel Wrote:I was successfull to store pictures worth more than 32Kb in one bank (The pictures for "Star Trek Classic", I displayed on my homepage), so storing 160 Kb using the compressor+compiled code should be possible. Sure, I need a bufer in low memory (in this case 3888 bytes), but such a bufer can be also reused for many other things, also for flickerfree animations or temporary storage of picture. I also like this solution for many reasons: It's already being used in other programs , and resembles a bit the LOAD! feature from Sinclair 128 BASIC. On the other hand, ZX BASIC aims to be a cross-platform compiler, and this is a very specific 128 BASIC issue. How did Z88dk manages this?
Anyway, I'm open to any suggestion regarding this, so WE can improve this in the future.
Posts: 615
Threads: 49
Joined: Feb 2009
Reputation:
2
boriel Wrote:I also like this solution for many reasons: It's already being used in other programs , and resembles a bit the LOAD! feature from Sinclair 128 BASIC. On the other hand, ZX BASIC aims to be a cross-platform compiler, and this is a very specific 128 BASIC issue. How did Z88dk manages this?
Anyway, I'm open to any suggestion regarding this, so WE can improve this in the future. I have no idea how z88dk solves this Problem. Maybe na_th_an will know?
Other Plattforms (Amstrad CPC 6128, Atari 130XE, MSX2) use similar bank system. I can easy adapt also the Scorpion ZS256 Turbo+ or Pentagon 1024 bank systems, and knowing the architecture of the other systems, there will be surely no big problem to adapt BorIDE for it.
Posts: 73
Threads: 9
Joined: May 2010
Reputation:
0
boriel Wrote:How did Z88dk manages this?
It doesn't. You have to do it by hand. Move the stack to a safe place, switch to RAM n, copy/unpack what you need to low ram, switch back RAM 0. That's how it's done, and z88dk has no means to do it. You have to do your own paging and copying/unpacking routines.
In our games we unpack directly to the memory addresses used in the games. We don't have scratchpad buffers. When we need a new map, we unpack from RAM n to the actual array where the map is stored in low RAM. Same for graphics.
Some time ago we made this same approach work in ZX Basic. Check here. <!-- m --><a class="postlink" href="http://foro.speccy.org/viewtopic.php?p=33120#p33120">http://foro.speccy.org/viewtopic.php?p=33120#p33120</a><!-- m --> there's much babble and gibberish, and it's in Spanish, but finally the work gets done.
|