Image Map Image Map
Results 1 to 7 of 7

Thread: Problem poking holes with MBASIC on a Kaypro 4/84

  1. #1
    Join Date
    Jan 2010
    Location
    Kingston, NS, Canada
    Posts
    41

    Default Problem poking holes with MBASIC on a Kaypro 4/84

    Okay so I'm not actually poking holes, lol. But I'm trying to run a program written for an old EPROM programmer. The initialization routine as follows:

    Code:
    240 BA=28672
    250 FOR X=BA TO BA+8192
    260     POKE X,255
    270 NEXT X
    always hangs when it gets to memory location 33779. I did a peek before the basic program is loaded and it is 0. But after I load it (but have not run it) the location is 26. I can start MBASIC with the /M switch to reserve memory but I can't do that with a value low enough (i.e. 33779) as that doesn't leave enough memory for the program itself to be loaded.

    If I change the starting value in line 240 to be 8192 less than 33779 it runs to near the end then craps out with a syntax error (but no line number). When I list the program it has erased itself from all after line 270. Obviously I am missing something but I haven't found it reading what old manuals I can find. Ideas?

    Thanks,
    Doug

  2. #2

    Default

    I don't think you can make any assumptions about availability of memory in MBASIC. I would assume you are poking MBASIC program code or data structures, causing any kind of havoc. Unless you have reliable information about how MBASIC uses memory, this is not likely to work. I have seen MBASIC programs that used CP/M entry points to figure out how much memory it could use. Perhaps that is the direction to go.

  3. #3
    Join Date
    Jan 2010
    Location
    Kingston, NS, Canada
    Posts
    41

    Default

    Quote Originally Posted by durgadas311 View Post
    I don't think you can make any assumptions about availability of memory in MBASIC. I would assume you are poking MBASIC program code or data structures, causing any kind of havoc. Unless you have reliable information about how MBASIC uses memory, this is not likely to work. I have seen MBASIC programs that used CP/M entry points to figure out how much memory it could use. Perhaps that is the direction to go.
    The program was written in MBASIC by the EPROM Programmer manufacturer for CP/M but not any specific machine. Regardless, when MBASIC reports how much memory is free [PRINT FRE(0)] after the program has been loaded should not that memory be free to “poke”? Surely it is contiguous is it not?

  4. #4

    Default

    FRE(0) tells you amount of free memory currently available to MBASIC. It does not tell you the location of memory that MBASIC will never use. It's been a very long time since I wrote MBASIC code, so all these details are foggy. But MBASIC will consume more memory as it executes, for variables and such. It also goes through "garbage collection" periodically in order to reclaim memory it no longer needs. But I'm not convinced you can make any assumptions about where that memory is, or even that it is contiguous. You will need to reserve memory when running MBASIC.COM in order to be able use some like this, but I don't recall how you determine where that memory starts. I think you are specifying the upper-most memory that MBASIC can use, and everything above that is available. But there is probably a lower limit that can be specified as well.

    It might help to see the original program, in order to understand how it might have worked on a different platform/environment.

  5. #5
    Join Date
    May 2009
    Location
    Connecticut
    Posts
    3,749
    Blog Entries
    1

    Default

    Quote Originally Posted by Doug_M View Post
    The program was written in MBASIC by the EPROM Programmer manufacturer for CP/M but not any specific machine. Regardless, when MBASIC reports how much memory is free [PRINT FRE(0)] after the program has been loaded should not that memory be free to “poke”? Surely it is contiguous is it not?
    What version of MBASIC are you using? The manual I have says that locations beyond the 32k limit need to be negative (location - 65536) with 8k BASIC. May not apply in this case but it was the first thing I could remember with problems near the 32k boundary.

  6. #6
    Join Date
    Jan 2010
    Location
    Kingston, NS, Canada
    Posts
    41

    Default

    Quote Originally Posted by durgadas311 View Post
    FRE(0) tells you amount of free memory currently available to MBASIC. It does not tell you the location of memory that MBASIC will never use. It's been a very long time since I wrote MBASIC code, so all these details are foggy. But MBASIC will consume more memory as it executes, for variables and such. It also goes through "garbage collection" periodically in order to reclaim memory it no longer needs. But I'm not convinced you can make any assumptions about where that memory is, or even that it is contiguous. You will need to reserve memory when running MBASIC.COM in order to be able use some like this, but I don't recall how you determine where that memory starts. I think you are specifying the upper-most memory that MBASIC can use, and everything above that is available. But there is probably a lower limit that can be specified as well.
    That's it, thanks! I had tried starting MBASIC with the /M: switch but I had things mixed up. When I tried it just now with /M:38000 and then changing line 240 in the program to start at 38001 it worked like a charm.

    It might help to see the original program, in order to understand how it might have worked on a different platform/environment.
    The manual with the program is here: https://usermanual.wiki/Document/JE6...051278298/view

    The program starts on page 4 (page 8 by the PDF viewer's count).

  7. #7
    Join Date
    Jan 2010
    Location
    Kingston, NS, Canada
    Posts
    41

    Default

    Quote Originally Posted by krebizfan View Post
    What version of MBASIC are you using? The manual I have says that locations beyond the 32k limit need to be negative (location - 65536) with 8k BASIC. May not apply in this case but it was the first thing I could remember with problems near the 32k boundary.
    5.21. I'd read that too and the manual I was reading said that the "disk extended" version could go up to 65536. Still I had tried altering the program to use location-65536 after 32768 but to no avail. The /M switch reserving a chunk of memory was the solution.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •