FAQ  •  Register  •  Login

IM 2

<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Thu Jul 26, 2012 7:55 pm

Re: IM 2

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

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Fri Jul 27, 2012 6:57 am

Re: IM 2

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

Posts: 596

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Fri Jul 27, 2012 7:52 am

Re: IM 2

Why you use A=0 and not A=16?
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

na_th_an

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Fri Jul 27, 2012 9:09 am

Re: IM 2

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

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Fri Jul 27, 2012 9:11 am

Re: IM 2

Man, you are my saviour :D 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

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Fri Jul 27, 2012 2:15 pm

Re: IM 2

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

Posts: 282

Joined: Sun Feb 13, 2011 3:33 am

Location: Kentucky US, used to be Birmingham UK

Post Fri Jul 27, 2012 4:26 pm

Re: IM 2

no wonder few companies took advantage of 128k of Ram
<<

LCD

Posts: 596

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Fri Jul 27, 2012 7:54 pm

Re: IM 2

na_th_an wrote: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" :).
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

boriel

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Sat Jul 28, 2012 8:52 am

Re: IM 2

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

britlion

Posts: 766

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Sun Jul 29, 2012 12:56 pm

Re: IM 2

na_th_an wrote:Has anybody done it before?


Yes.

Here: post962.html?hilit=im2#p961

And also, as a matter of fact, here:

http://www.worldofspectrum.org/infoseek ... id=0027713

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


[Not 128K though!]
<<

na_th_an

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Mon Jul 30, 2012 8:53 am

Re: IM 2

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

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Mon Jul 30, 2012 8:58 am

Re: IM 2

na_th_an wrote: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

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Mon Jul 30, 2012 8:59 am

Re: IM 2

Downloading right now, thank you :)
<<

na_th_an

Posts: 73

Joined: Fri May 07, 2010 7:34 am

Post Mon Jul 30, 2012 9:02 am

Re: IM 2

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

Site Admin

Posts: 1463

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Mon Jul 30, 2012 9:04 am

Re: IM 2

na_th_an wrote: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).
PreviousNext

Return to How-To & Tutorials

Who is online

Users browsing this forum: No registered users and 1 guest

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore.

phpBB SEO