Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IM 2
#26
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 Smile Meet this requirement, and you can make 128K programs Smile
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 1 Guest(s)