Commander X16

28 minutes ago, SlithyMatt said:

Ah, that's the harder part in BASIC. Unfortunately, BASIC doesn't support pointers, much less far pointers, so you'll still need to poke the bank number and peek at addresses to read the values back. That means one byte at a time, so even if you are storing strings, you'll need to deal with them as arrays of character indices.

Oh...nuts. That's not good. So, at current, there's no way to simply reference a bank and a name?

So, if I wanted to continue, I would need something to reliably read....some place within a given bank and bytewidth in order to properly cast information and return it.

So, something like:

10 REM //SUBROUTINE - BANK ACCESSOR
20 REM //INPUTS - B% - BANK #, A% - ADDRESS?, W% - BITWIDTH,
30 REM //IFS ON W% BEING 1,2, OR 3 ASSIGN R AS RETURN AND RETURN
40 RETURN
	

Yeah, so This means I need documentation on both the banks used, the memory addresses statically assigned, and - basically no dynamic assignment or allocation or names within the banks.

Lame. Depressing, even. I will have to cut features.

Yah, there are two separate (but equal!) feature requests for BASIC commands to easily move memory between Low RAM, banked RAM, banked ROM, and Video RAM.

In some ways, the separation of these memories means each is kind of like a separate device; presumably, an abstraction layer that treats them as separate devices might be part of the solution.

(1) how to deal with type data, e.g. can you move memory by type?  E.G. "float poke/peek", "uint poke/peek", and "string poke/peek"?

(2) what are the most useful destinations for banked data? Some brand of memcpy() is useful but not enough.

(3) how to avoid excessive POKE and PEEK altogether.  

(4) should you be able to PRINT directly from banked memory, avoiding an intermediate variable?

(5) can we arrive at uniform/overloaded functions that can copy from both banked RAM and ROM and VIDEO RAM?



Germane topics include the BASIC 7 command "POINTER", as well as BLOAD and BSAVE.

Discussion at: https://github.com/commanderx16/x16-rom/issues/127

and https://github.com/commanderx16/x16-rom/issues/17

45 minutes ago, rje said:

Yah, there are two separate (but equal!) feature requests for BASIC commands to access bank memory better than POKE and PEEK.  In effect, proposals to do memory copies.  Issues to be decided include:



(1) how to deal with type data, e.g. can you move memory by type?



(2) what are the most useful destinations for banked data?  Apparently, memcpy() is useful but not enough.



(3) how to avoid excessive POKE and PEEK altogether.  



(4) should you be able to PRINT directly from banked memory, avoiding an intermediate variable?

Yeah, another consequence of having arrived a bit early to the party. There's still a lot to be designed and built, and maybe, in my own amateur-hour-millennial way - can help through suffering - that's fine. XD

Not the place for this, BUT since it's relevant to the immediate problem:

1 - This would be ideal. we're dealing with 512K, so we have plenty of room to create intermediate structures for managing segments of addresses and thus data. The Low Ram presumably already does this (The C64 certainly does) - so why not allow the High Ram to do the same, if the programmer wishes it? It's the most novel resource of the machine. In essence, asking a bank to act in a similar manner to the Low Ram isn't a stretch in terms of design.

2 - Probably solved by some method related to 1. 

4 - Yes. If you can solve the type enforcement, you automatically have the path towards running commands directly on higher ram.

I'd throw this on the issue posts, but I worry that I might be a bit out of my own depth and the comments unwelcome.

 

As for RetroTrek itself, I'm kinda halted except for small things. I'm currently implementing things in an untested state, namely combat mechanic functions like checking if the shields are down, damaging a random system, etc. The bottom and top bars are much better now; they and the SYSTEMS panel now have lots of useful information. The top bar now shows the current RAM free.

It seems like, as soon as this is over, that things like generating the sector map will be easier, but expensive and slow. I will want something to display "PROCESSING..." while that intense stuff goes on. I am wondering if I can make a standard for subroutine inputs and outputs such that it uses the fewest variables but takes the fewest lines/chars to document in-code.

5 minutes ago, Starsickle said:

Oh...nuts. That's not good. So, at current, there's no way to simply reference a bank and a name?

You can store bank numbers and addresses into BASIC variables, but you can't automatically dereference those pointers in BASIC. So, you can load a data file to a set of banks with LOAD, and use BASIC variables to keep track of the bank numbers that contain different kinds of data, or arrays that contain bank and address pairs, all of which will need to be hardcoded based on a static map of your data file. If you have variable-length data, you can traverse that in basic and store length values, too. But definitely, you're hitting the top end of what's feasible with BASIC. It may be time to consider using C or assembly to create some routines to handle that data that you can use SYS calls to run. I just posted a video that can help get you started on using cc65: 


 

 

But if you want to continue with BASIC, you can do something like this:

Say you have a data file (DATA.BIN) larger than 8k, so that you have values you need to access at offsets $1234 (FU) and $2468 (BR). So, you load it starting at bank 3 (BM), meaning it will spill into bank 4 (BS), putting those values in RAM at 3:B234 and 4:A468.

10 BM = 3

20 BS = BM + 1

30 LOAD "DATA.BIN",8,3,$A000

40 FP = $A000 + $1234

50 BP = $A000 + $2468 - $2000

60 POKE $9F61,BM

70 FU = PEEK(FP)

80 POKE $9F61,BS

90 BR = PEEK(BP)

 

Honestly, if the workflow in C is nothing more than do what I do in C Projects? Shove it into some machine  - get a PRG file? I might consider it. But I would want ALL of C. All of it. Checking the video; it's promising, but I'm uncertain.

I have a little experience with C, but my experience was rife with environment setup and workflow problems than actual design and programming. Thus is the destiny of Windows C/++ development without an IT department.

I think, at least for now - I'm best served IRL by waiting on the design and engineering issues at hand before diving any deeper.

Developing with C for Windows is a bad comparison to cc65 and the X16. By necessity it is much, much simpler. You'll want just a single PRG and just link everything to that. If you use my makefile, you are all set to create a set of .c and .h file with a sinlgle main function and link it all together. You won't need to link a bunch of libraries in, as the basic clib and X16 kernal stuff is automatically linked in if you reference it.

And I'm not sure what you mean by "ALL of C". Do you mean a particular C standard, like C18? C is by its very nature a systems language, so its use is tightly constrained by your target system. In this case, it's as simple a system as you can realistically use C for. So, no heap, no floating point math, and no structs on the stack. But otherwise, anything that you would do with a C program is possible, and that pretty much covers what you can do with the X16, anyway. BASIC does give you floating point, but at an enormous cost because it's for everything all the time.

What you will get with cc65 is the ability to have named pointers, structs and scalar variables. And those names can be larger than 2 characters! You can easily reference strings and binary data blocks anywhere in memory and use the standard C functions with them. Doing that stuff in BASIC is a complete nightmare and completely negates the "ease" of BASIC programming relative to C.

Just some things to consider, as you obviously want to create a very involved game, and I'd hate to see you stymied by something that is easily overcome.

Quote

I



t seems like, as soon as this is over, that things like generating the sector map will be easier, but expensive and slow. I will want something to display "PROCESSING..." while that intense stuff goes on. I am wondering if I can make a standard for subroutine inputs and outputs such that it uses the fewest variables but takes the fewest lines/chars to document in-code.

You can also give the user something to read while the map is generating: for example, a command summary, or a selection of useful tips.  Something that fits on one screen.  (Yeah, I know, you might have to bank THAT as well).

One other option, in the spirit of "divide and conquer", is to have a separate, GALACTIC CONTROL program that generates maps, and writes them to files, and allows you to specify the "current" map.

Then the main program would simply load the "current" map.

Not the best screenshot, but here's the last time it worked without running out of memory:



I was just about to get the Mask and Player Position "@" working.

That's actually an exciting layout, Starsickle.  All those views and statuses and so on... and the reverse text on the bottom... the classic greentext terminal on black... very nice.

On 9/16/2020 at 11:11 PM, SlithyMatt said:

You can store bank numbers and addresses into BASIC variables, but you can't automatically dereference those pointers in BASIC....

Yes, that's the crux of it. We need some V2 Basic hackers to have a go at some of the proposals in Issues on GitHub, or it will not happen in RomBasic. xForth debugging took me straight through to the end of summer vacation, and learning the ins and outs of ca assembly isn't really going to happen in the middle of the Semester, so that's not going to be me. That is, not unless it is the associative arrays in High RAM as device 7, which is a Kernel level expansion that Basic can use, and so can be programmed in acme, otherwise I am just on the sidelines cheering.

My number one extension I would cheer for is HDIM to allocate arrays within $A000-$BFFF, and then if you have a parallel data structure across multiple banks, simply change the bank and the arrays reference all the parallel data in that bank.

Edit: It just occurred to me that USER() might be give an array fill from HighRAM routine, that's a second thing that could be attempted from Acme.