Thread: Converting MINI-BASIC in MASM over to C++?

>> To make it "binary compatible" with the existing assembly code, I think reading documentation may not be sufficient.

Good point.

PEEK and POKE work within the code itself - we may need to change the way the code is stored to solve that. Let's ignore PEEK and POKE for the very moment.

Locate is a "gotoxy()" type function to move the cursor.

--
Mats

I had a quick look a the "pitman.mbi", and it looks like it's using PEEK and POKE to store extra data. It's essentially building data structures in memory, and reading them back in other places.

So we need to make PEEK and POKE available. But we probably just need a section of memory available for the purpose.

I improved the "LET" command a bit:

Code:

void LET(const char *str)
{
	int *ptr;
	if (GetVariableAddress(&str, &ptr))
	{
		if (SkipSpaces(&str, '='))
		{
			if (!EvalExpr(&str, ptr))
			{
				SyntaxError();
			}
		}
	}
	
}

Saves an if-statement and a str++. And gives a "SyntaxError" if the expression is not valid.

--
Mats

>> Saves an if-statement and a str++. And gives a "SyntaxError" if the expression is not valid.

Ah, yeah that works much better. I hadn't really dealt with the syntax error issue at all. I guess I should amend the other parsers as well.

By the way, the internal use of longjmp kind of unnerves me. I know that it's probably safe, but couldn't it potentially cause problems if code with ctors/dtors is introduced?

>> I've patched some 'init' and 'shdn' stuff as well as fixed the resize function--I think.

Cool, I'll patch that in as soon as I have a chance. I was actually thinking we could rework all of the console I/O to make it more modular. I have some Win32 specific keyboard translation code laying around somewhere that could help with the input side.

Ok, so the original usage of PEEK/POKE was to access such things as video memory, io ports, and operating system data structures, is that correct?

>> A simple "increment the pointer" allocator partially specialized on a wrapper type, distinguishing between `int' and `wrapped<int>', passed to the relevant containers--including in this case the equivalent of `std::string'. Of course, using a simple map with a key of `LINE_NUMBER / 128' wouldn't be exactly difficult.

Could you give a concrete example, please.

Could you give a concrete example, please.

Scratch the allocator approach... of all the compilers I have only Comeau with Dinkumware seem to do the job exactly right. Everything else uses extensions that mess with the simple logic.

As for the other approach, the original only allows for 32767 lines with 255 characters per line. That's about 8 MB. I was saying to split that into 512, or more, chunks. The first chunk would be passed, indifferently, to the allocators for the program logic. (This really is simple if you have an existing allocator.) The second chunk is the integer array. The next four chunks are the "freeplay" area. (The 64 KB memory area used by the original source.) The remaining chunks, are allocated on an as needed basis to store the program itself. Within `PEAK'/`POKE ' some simple modulo mathematics gives you which chunk to jump to where if it doesn't exist you allocate it. The same logic tells you where to process the current line.

You could use a different storage approach, but this will probably use the least memory compared to many other approaches simply because of the way most BASIC programmers number the lines.

Soma

Edit: Yea, I really barfed on my original map example.

Tossed source; horribly broken!

I don't know. I really don't see the point in sticking with those old, hard-coded limits. I would rather not put any unnecessary restrictions on the user at all. I would recommend allowing lines of any length and number, limited only by available memory. The same goes for the '@' array. It could easily be resized during accesses. As for PEEK/POKE, these could be treated much the same way. Start them out as empty buffers, and allow them to grow as necessary. No?

O_o

The remaining chunks, are allocated on an as needed basis to store the program itself.

Nothing would stop you from allocating and spacing for additional chunks.

Code:

my_map[0] = new unsigned char[16384]; // divvy up for program logic
// my_map[1] - my_map[65535] reserved for additions
my_map[65536] = new unsigned char[16384]; // divvy up for integer array
// my_map[65537] - my_map[131071] expands for larger array
my_map[131072] = new unsigned char[16384]; // expansion array 1
// ...
my_map[1048576] = new unsigned char[16384]; // source area

All I was saying, and my logic is still wrong, but I'm too sleepy to correct it, was that you could map 16384 byte chunks into play as you need. Further, I was suggesting a specific layout--which my broken logic failed to show.

My first suggestion was to map the first few chunks into memory as program logic bits. (Allowing you to trash the system and blow your leg off just like in real programming.)

My second suggestion was to map the next chunks into memory as the integer array. (There is nothing stopping you from mapping additional chunks as part part of the integer array.)

My final suggestion was to map the first "source area" chunk, say 1048576, (6 in my other example) to lines 0-5-10-[...]-305-310-315; lines 1-6-11-[...]-306-311-316 to chunk 1048577; lines 640-645-650-[...]-945-950-955 to chunk 1048586; etc..

It is just an odd layout for something like a sparse array of source lines implemented with maps and arrays.

Yes, it has limits, but practicable ones. The integer array would allow for 1 GB. The "source array" limited by available memory. The line length only limited to 16384 characters. You could easily push these limits up by increasing the distance between the reserved areas or the chunk size.

Edit: In case there is still some ambiguity, I don't care about *where* the limits are set. (They could even trivially be set during run time with compiler-like flags.) The limits only allow for a few tricks to simplify implementation, and they are rather efficient. Simply "growing" to fit every situation is wasteful. I don't like it. Now there is nothing wrong with using maps or sparse arrays everywhere if that's what you want to do, but I probably wouldn't do it that way.

Soma

I see what you mean. I guess I was just thinking of something a little more simple, along the lines of:

vector< string > commands;
vector< unsigned char > poke_buffer;
vector< int32_t > array_buffer;

Or perhaps mapping the last two buffers into one, so that poke_buffer[ 12 ] would be the byte located at array_buffer[ 3 ].

The @ array can hold up to 2000 elements, and more if needed.

>_<

Yog Sothoth!

I *HATE* crap like that.

Can it hold "up to" 2000 elements? Or can it hold "more than" 2000 elements?

They are different!

Or perhaps mapping the last two buffers into one, so that poke_buffer[ 12 ] would be the byte located at array_buffer[ 3 ].

Well, that's part of the rationale for my suggestion... where `poke_buffer[$]' may alter the source during execution, the interpreter, the integers, the integer array, and even the "play area" that it is supposed to poke.

Soma