IM 2

[boriel]

Remember to preserve IX and IY registers (IX is used in ZX Basic for function stack frames and IY could be used in some ROM-calls).

[na_th_an]

I do: the ISR saves all the register pairs. Check the code and see

But that's not the problem. The problem occurs with bank switching. Just with bank switching, even if I don't enable my ISR or even don't enable IM2, any bank switching messes subsequent PRINT calls. Minimal case scenario:

Code:

' Test

Asm

    ; Permorm some dummy paging
    
    di
    ld  a, 5
    ld  bc, $7ffd
    out (c), a
    
    ; now RAM 5 is in.
    
    xor a
    ld  bc, $7ffd
    out (c), a  
    ld  ($5b5c), a
    ei
    
    ; back to normal
    
End Asm

Print "HOLA";

Compile and run this in either 128 BASIC or USR 0 mode. You won't see "HOLA" on screen, but a bunch of trash.

So no clue? That's bad I really need PRINT, in fact I'm doing this in BASIC 'cause I can print to the screen with no hassle.

Also, the aplib decompressor also messes up something. Whenever I use it (not only with this project), the PRINT output gets BOLD.

[LCD]

Why you use A=0 and not A=16?

[na_th_an]

Because I'm paging RAM 0... I've always done it that way in all my 128 games. I'll try a=16 to check if it's more ZX Basic friendly. Anyways, bit 4 is used to select ROM0 or ROM1... So maybe that makes sense, if PRINT needs the 48K ROM paged in...

Thanks, I'll try that

[na_th_an]

Man, you are my saviour Indeed PRINT needs ROM1 paged in. Good to know!

Now I'm ready to finish and release the multicolour lib. You'll be in the "special thanks" section for sure

[boriel]

ZX BASIC print routine does not use the ROM, if I recall correctly. It's a faster-smaller reimplementation (about 400-500 bytes) with OVER 2, OVER 3, ITALIC and BOLD Effects.
In fact, switching memory banks can exchange the HEAP, and usually top 16Kb blocks are used for the heap (from 0xC000 to 0xFFFF). Can you also check if this affect your program?

In other words: The compiler is not ready for 128Kb machines. We should design how this could be achieved. It's much harder than one could think.

• A 1st approach: use the classic method (as in Sinclair +2 BASIC) of using the extra RAM as storage. This could be the easiest way, and should not require many changes in the compiler.
  
• Another approach is to use a different address scheme. Eg. When calling the function, or using PEEK/Poke, the compiler could use a scheme like PEEK(BANK:Address) (similar to PC Segments). Each bank will be indicated with a byte, so each memory address will take 3 bytes and could have an impact in performance and space. On the other hand, it will allow using the entire memory as if it were linear, but asm inline routines should be rewritten taking this into account). :S Looks nice, but I'm scary of it.
  
• 3rd approach: Embed all the code in functions (even the MAIN one is in another fuction; C already does this with its mondatory main() {} ). And try to fit ever function within blocks boundaries. This is really hard also, but very attractive. Again, I'm not sure this is a good approach.
  
• Similar to 1st: Use the top 16Kb as a "swapping" block for the heap, graphics, extra functions, interrupts and whatever. I like this approach but don't know how to implement it in a general way (e.g. to be used in a generic way for every programmer).

[slenkar]

no wonder few companies took advantage of 128k of Ram

[LCD]

Because I'm paging RAM 0... I've always done it that way in all my 128 games. I'll try a=16 to check if it's more ZX Basic friendly. Anyways, bit 4 is used to select ROM0 or ROM1... So maybe that makes sense, if PRINT needs the 48K ROM paged in...

Thanks, I'll try that

You are welcome. You helped me too with "Nanako" .

[boriel]

A question: Are you saying ZX BASIC PRINT uses ROM? (It shouldn't). :?: hock:
In fact, I created a standalone PRINT routine (shorter, faster and independent of ROM precisely for using ALL-RAM (128Kb) mode, etc.).

[britlion]

Has anybody done it before?

Yes.

Here: <!-- l --><a class="postlink-local" href="http://www.boriel.com/forum/post962.html?hilit=im2#p961">post962.html?hilit=im2#p961</a><!-- l -->

And also, as a matter of fact, here:

<!-- m --><a class="postlink" href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027713">http://www.worldofspectrum.org/infoseek ... id=0027713</a><!-- m -->

(The timer hops between IM 1 and IM 2 as needed to keep time).


[Not 128K though!]

[na_th_an]

If PRINT doesn't use ROM at all, then something has to which later on interferes with PRINT, just check my last example in this thread. It just pages RAM 5, then pages back RAM 0 (and ROM 0), and then PRINT is broken.

The thing is, there's no problem with interfering with the heap as while I have another RAM paged in I do NOTHING in the realm of the runtime, I mean, the paging stuff is done on spot and then everything is set back to normal.

So this is very strange. If I page pack RAM 0 but leave ROM 0 in, subsequent PRINT calls output gibberish. I have to page RAM 0 *and* ROM 1 to work. So maybe there's something else which needs ROM1, and somehow interacts with PRINT?

The compiler works great as is right now, I mean, if you use the extra RAM as a data storage facility, as I usually do. The same happens to z88dk, it's not very "128K ready" (not even aware), but it's perfectly usable. You just have to remember, in the case of ZX Basic, that ROM 1 must be paged in Meet this requirement, and you can make 128K programs

[boriel]

The compiler works great as is right now, I mean, if you use the extra RAM as a data storage facility, as I usually do. The same happens to z88dk, it's not very "128K ready" (not even aware), but it's perfectly usable. You just have to remember, in the case of ZX Basic, that ROM 1 must be paged in Meet this requirement, and you can make 128K programs

Please, check the latest version (uploaded just yesterday). It shouldn't crash when you try to convert a string into a byte (but complain with an error instead).
Also, I will check your example today to see if I catch why ROM paging is crashing the compiler.

[na_th_an]

Downloading right now, thank you

[na_th_an]

By the way, I've fixed the aplib decompressor and now it works flawlessly, are you interested? It includes a SUB

Code:

Sub aplibUnpack (source as uInteger, destination as uInteger)

Which decompreses an aplib-compressed binary from source to destination. May come handy for all of us The ASM sources (by dwedit, utopian and metalbrain) have been cleaned and also use a prefix for all labels, so it shouldn't interfere with other libraries.

[boriel]

By the way, I've fixed the aplib decompressor and now it works flawlessly, are you interested? It includes a SUB

Code:

Sub aplibUnpack (source as uInteger, destination as uInteger)

Which decompreses an aplib-compressed binary from source to destination. May come handy for all of us

Of course! I can include in the ZX Basic library. In fact, there is a /mj/ directory (Mojon Twins).
So always use:

Code:

#include <mj/LIBRARY>

when using MJ libraries (e.g. optimized fourspriter is there).