Thanks Ken! This is exactly what I was looking for! I guess there's no real reason to be coy about this. I've got the 8080 assembly source for a FOCAL interpreter that dates back, to 1975! First I was just using it as a test case for the asm80 cross-assembler, but then I made the mistake of actually trying to run it, which meant fixing the bugs that dated back to 197x, and that has lead to me trying to add CP/M file I/O to it, because I want to know CP/M at that level.
But I can't look at all the IF'ed out code sections (machine and serial-card specific console I/O) dating back to the 8080 bare-metal days and think "It might be amusing to port this to the M100." Utterly useless, unless someone has a desperate need for 32-bit binary floating point math instead of BCD floating-point, but amusing. And the madly dynamic M100 system is just about as different from the old S100 bare-metal systems as two 808x machines can get! I'm not saying I'm going to do this. In fact I'll even say I shoudn't. But I might anyway. :-) Willard Sent from Samsung tablet -------- Original message -------- From Ken Pettit <[email protected]> Date: 02/01/2017 8:23 AM (GMT-07:00) To Model 100 Discussion <[email protected]> Subject Re: [M100] Assembly question: free RAM Hi Willard, Actually, all files grow upwards from the bottom of RAM. BASIC files are first, TEXT files are second, .CO files are last. As you add lines to BASIC or TEXT files, everthing just shifts up. So free space at the top is truly free. But when you edit a TEXT file, anything in that free space will be wiped out. When you launch TEXT to edit a file, the first thing TEXT does is expand that file to occupy all remaining RAM. It does this by shoving all files that are higher in RAM address to the very top, then allocates the space in-between to that file. That way as you are typing, the performance is better because it doesn't have to move every file with each keystroke. Then when you exit TEXT, it compresses the file back to the required size by moveing the higher files back to low RAM. Yes, there are pointers for the start of .BA, .DO, .CO, BASIC Variables. From Virtualt's src/m100rom.c file: 0xF99A, /* Address of unsaved BASIC prgm */ 0xF9A5, /* Address of next DO file */ 0xFBAE, /* Start of DO file area */ 0xFBB0, /* Start of CO file area */ 0xFBB2, /* Start of Variable space */ 0xFBB4, /* Start of Array data */ 0xFBB6, /* Pointer to unused memory */ 0xF5F4, /* Address where HIMEM is stored */ 0xF88C, /* End of RAM for file storage */ 0xFAC0, /* Lowest RAM used by system */ 0xF962, /* Start of RAM directory */ Ken On 1/31/17 11:14 PM, Willard Goosey wrote: I know BASIC files grow upwards from the bottom of RAM, and other files grow downward from the top. Are there system pointers to the end of BASIC files and the end of data files? I'm thinking of a .CO file that would need a fairly large buffer space... Can I just put my (volatile) data in the free space between files or do I need to formally create a file and size it before using that space? It would NOT be ASCII data... And would the rules be different for an OptROM? Willard Sent from Samsung tablet
