Jump to content
Starsickle

RETROTrek - Early Development Thread

Recommended Posts

Because it's easy, I implemented long variables in my pre-processor.  So I pre-declare with

 

longvar /my_long_var_name$  ml$

 

And the pre-processor keeps two maps (in both directions) and complains if something gets stomped on.

 

Of course, if I don't pre-declare a short variable, I can still stomp on it all day long.

 

Share this post


Link to post
Share on other sites
34 minutes ago, SlithyMatt said:

Atom does have BASIC support, but it also has a really nice package for 6502 assembly, supporting all the major assemblers including ca65.

Nice. I'll have to check that out. I've been toying with Atom for Python earlier this year; I'll give it a spin on BASIC, now. Any helpful links/extensions appreciated.

As for the game, I've gotten some basic data stuff working. Apparently I have to separate String arrays from numerical arrays, so the ship data will be split up between two arrays that contain string information and numeric information. This creates a big problem for dynamically managing these memory spaces, but I've decided early versions of the game will not have randomly generated content and instead have static content first. There will be ten ships in these early versions.

With that solved, at least for now, I'll move onto implementing those ships and various rules into the game. For now, I'll be working towards the Phase I implementation of the game's structure - 10 Sectors.

 

In general - Ships will have a Scale, which determines various other stats like its systems, crew, and torpedos. You damage systems until the engines or structure are at 0 - after which the ship is destroyed. Tracking this will be messy at first, but a simple isDead flag will have to do. As well, Scale will determine how many crew and away team may be deployed to board a vessel. These are mechanics I'd like to finish later, but would be interested in since they appeared in DOS/Tandy1000 games.

The available weapons to start will be Phase Cannons, Torpedos, and the risky but powerful Particle Beam.

Edited by Starsickle

Share this post


Link to post
Share on other sites

Back to RETROTrek.

These retro space games need a purpose.  As I recall, the Trek games I played way back when involved hunting down and (ahem) neutralizing enemy ships -- cleaning out a region of space.  Starbases would be available for repairs, reloading, perhaps for refitting, or whatnot.

Is that RETROTrek's mission?

 

Share this post


Link to post
Share on other sites
1 hour ago, rje said:

Back to RETROTrek.

These retro space games need a purpose.  As I recall, the Trek games I played way back when involved hunting down and (ahem) neutralizing enemy ships -- cleaning out a region of space.  Starbases would be available for repairs, reloading, perhaps for refitting, or whatnot.

Is that RETROTrek's mission?

Yup! I spent more of today doing the README, so here's some snippits.

Quote

There are three planned game modes for RETROTrek:
    
        1. Explore - The objective is to explore all the bodies in the game.
        2. Secure - Destroy all hostiles in the game.
        3. Contact - Make contact with each other species.

    Explore will be the primary supported game mode and will be worked on first, followed by the other two.

These will be tracked by an objective variable. PHASE I will simple have it advance each time you successfully finish a single sector. After the maps are ready, then it'll get much better.

Here's what I got for the Attack sequence:
 

Quote

THE ATTACK AND DEFENSE SEQUENCE:

    For this example, we will use the example of The Endeavor versus a Klorg Heavy Cruiser - which have equal stats.

    1. The Endeavor issues a command to Fire (FIR) its
    2. Phase Cannons
    3. At the Klorg Heavy Cruiser.
    4. The game determines if it is hit. For this, it needs a few numbers.

    Firstly, we need two numbers representing ToHit and Evade. For every point of the the user's WEAP, that is 16 percentage points. For every point of the Target's ENGI, that is 5 points.

    If the target's Engines (ENGI) are operating, it consumes Power (PWER) to attempt to evade automatically. If it doesn't have this power, it gain the defensive points.

    5. Upon Hit, damage is applied to a target's shields (SHLD). If no shielding is available, a random System is damaged.
    
    6. Also upon hit, an amount of CREW are injured. Crew are Injured depending on weapon type.

THE BOARDING ATTACK SEQUENCE:

    Boarding attacks can only be done if a target's shields are down.

    Using the Away Team (AWY) command, the attacker spends energy to send crew to board and attack the target. The game does some random number stuff, and defenders and attackers take casualties. If the enemy crew are 0 at the end, then the target ship is captured.

This could open the way for capturing as objective, but - as always - baby steps and base cases first.

Here's how ships will generally work:

Quote

Before you get yourself into the Captain's Chair, it's important to understand how every ship works:

CRITICAL STATS OF A SHIP:

    Firstly, every ship a base number called a Scale (SCAL), which is a general measurement of size and capability. Scale determines several other things about a ship, including its:
        - Shield (SHLD) Strength (SCAL*1)
        - Total Crew of a ship (SCAL*30)
        - Compliment of Torpedos (TORP) (SCAL*6)
        - Power (PWER) Storage (SCALE*1000)
    
    Shields (SHLD) protect a ship systems and Structure (STRC) from harm. If a ship's STRC reaches zero, it is considered destroyed.

    The CREW (CREW) of a ship are critical to its operation. A crewless ship is dead in space, and an angry crew can mutiny, resulting in a Game Over on successful Mutiny.

    The available Power (PWER) of a ship is the available power for hard activity. The CREW use PWER to carry out several actions both passively and actively.

SHIP SYSTEMS:

    All of the subsystems of the ship can survive up to 6 points of damage.    At 5 points of damage, they are rendered inoperative. At 6 points, they are destroyed.

    The Engine (ENGI) system provides the ship with power and flight ability. Disabled and Destroyed Engines are very bad for the ship.

    The Sensor (SENS) system allows a ship to see and detect what is happening. If Sensors are disabled or destroyed, the ship cannot see or scan.

    The Weapons System (WEAP) allows ships to defend themselves.

    The Communications System (COMMS) allows a ship to Hail Objects (HLO) in space. This can be used to:
        - Demand surrender (DMD)
        - Ask permission to dock (DCK)
        - Parley (PLY).

Make sure you take turns to engage with Repairs (REP) in order to fix damaged or disabled systems!
Systems that are destroyed are only repairable at a starbase. Make sure to protect your engines!

ALERT CONDITIONS AND OPERATIONS:

    As well, you need to know about how the alert condition of your ship influences its operation. The alert condition of the ship will (eventually) influence how the ship's systems and crews will operate

    CONDITION: NORMAL - The ship operates normally, focused on normal operation. CREW and PWER will attempt to fix the ship and keep systems running nominally.
    CONDITION: YELLOW - The ship is operating under risk. CREW and PWER will only passively be used to protect critical systems and prevent loss of life.
    CONDITION: RED - The Ship is operating as if it is under danger. CREW and PWER will at risk every time the ship is at risk.

So, every turn there's stuff happening actively and passively. That's the goal, at least. As of now, I'm implementing subroutines to act as accessors and mutators for some of the basic parts. I have a LOT to test, so I might have really messed up today by making such good progress.

I like this, so far, as it's a great mixture of all the trek games I've played in my youth. There's Crew, there's power, there's sim aspects, and it makes you think before you act.

  • Like 1

Share this post


Link to post
Share on other sites

Github project is up, although I'd like to use the Issues and Release functions of the site in order to help people submit bugs and issues. I am not sure if I can do that.
https://github.com/users/Starsickle/projects/1

Speaking of bugs, I sure did call it: After the code cleanup and some additions I definitely broke it. The game is currently doing everything fine up to drawing the screen like it used to, but it gets to a certain point when drawing various elements before - of all things - returning to the normal X16 color scheme and clearing the screen - and showing READY.

Wow. Okay. That will require some tracking down. I've already spent a lot of time on it, but I'm at the point of commenting out sections, but yikes. The loop and parts seem to be linked up fine, but I simply cannot explain the screen clearing and READY. - in the original startup color scheme - without hitting ANY of the designated program termination lines.

EDIT: Found the offending subroutine.

Anyways, secondary activities today involve setting up the bottom status bar, even though I'm having trouble with displaying them properly. I've come up with a solution to problems with constructing the sophisticate line. I'll simply write the line twice. Once for the bar, once for the text. Easy.

Edited by Starsickle

Share this post


Link to post
Share on other sites

I have LOTS to show off today! Today i finished 14 tasks, and can show off the working data generation, new command series, and something getting closer to a game!

First shot is of the current game screen. Everything's coming along. The bottom Status bar has been finished, but it could use some polish, as you can see with those final two troublesome spaces at Y59 and Y60. Second, a shot of the debug report of 3 of the 10 static data ships in the game. Here you can see they are read perfectly and ready to rock.

Finally - the thing I'm most happy about right now: The random generator for our mysterious space region works. Sadly, the array is referenced like AR$(Y,X), which is beyond confusing for all the double loops I will need, but it is what it is.

Mechanically, the spacial region designated "SUBQUADRANT BETA-3" is about 78% empty. This might require some adjusting, as there's a few problems with placing at least 1 of something I may need to solve to balance out gameplay. I think there's too many combined Starsystems (*) and Planetary Systems (O). I think I should adjust it down to favor Starsystems with more diverse features. This will need some work, but the general proof of concept looks good as far as empty space to non-empty.

Look at it, though! It works! IT WORKS! From here, I have a few choices to make with how to improve this design, including adopting a trinary representation of a Sector, and reserve what's here for a Local area in a sector much like the other trek-clones.

PHASE 1 seems to be coming along, though. I am currently chipping away at implementing a very basic set of features, but sometimes I get something more advanced done, so I'm moving faster than I think. I will eventually EDIT the OP and clean up these posts for the sake of Forum Cleanliness and Efficiency. I just want a bit more done.

RetroTrek-WIP13.png

RetroTrek-WIP12.png

RetroTrek-WIP14.png

Share this post


Link to post
Share on other sites

Once you get the feel of it, and get a cheat-sheet, you'll find the PETSCII graphics could be useful for defining the screen panels.  More pretty than rows of ========== and ************.

 

Share this post


Link to post
Share on other sites
25 minutes ago, rje said:

Once you get the feel of it, and get a cheat-sheet, you'll find the PETSCII graphics could be useful for defining the screen panels.  More pretty than rows of ========== and ************.

The problem is that I'm more likely to have programmed this whole thing on a Windows 10 64 bit system with some millions of times more RAM available, and in UTF-8 or ASCII - before the X16 is even available to us. I'd be using a lot of functions to stand in for those special characters, and while I'd love to take advantage of the PETSCII characters, I also know that there's ASCII characters I'd want to use to represent things I'd like to show the user. I definitely want to make it look nice, but I'd also want to make sure I can program quickly and cleanly. If we had the X16 right now, I'd of course be using its own keyboard, and perhaps drivers for its own keyboard on a modern system.

Speaking of which - I might wanna ask about/put that as a Driver/Software feature request...

Share this post


Link to post
Share on other sites

I get that... and yeah, at one point this summer I started writing assembly language that will draw a panel with a specified position and dimension.  Just another project to dust off and finish, because I want to use it myself.

I've got one in BASIC though, attached here, for your amusement.  One version you can load from the emu, and one that's ASCII.

 

WINDOW2.BASpanels.bas

Share this post


Link to post
Share on other sites

WELP

WELPOOM.png.2462c0b9acf7c0922a66af866df69412.png

OKAY...Time to cut some features and learn how to somehow offload...

RGN$(9,19,2) (Would like it 9,19,4)
SCTR$(9,9,4)

To other parts of memory. I do not know how to do this, but willing to hear ideas. I haven't looked at manipulating the High Ram, but I suppose it's time to learn.

Strings seem to be too heavy, and there's no way to define these as character arrrays, instead. A single character is 2 bytes, but a string is 3+? and that's a little mystifying because I'm reading different things, here.

After cutting a few things, I'm back up and running but I don't know how I'm going to link up Planets and Civs or Manage Ships...

Edited by Starsickle

Share this post


Link to post
Share on other sites

On a 512K system, you have 63 banks of memory available, with 8192 bytes in each bank.

Star Trek typically has an 8x8 quadrant grid, with 64 8x8 sectors.

So what you'd do is transfer data into BASIC memory each time the ship changes sectors. 

If you use 32 bytes per ship, starbase, or star, and you limit each sector to 8 objects, you could store the entire game grid in 16K of RAM, or 2 upper memory banks. 

The simplest way to deal with this is to store your data in fixed-length fields. For different types of objects, you can use object type IDs to separate them. So for example:
0=Ship, 1=Starbase, 2=Star

Then your records might look like:

  1. Record Type (0=Ship) *1
  2. Ship Name *16
  3. Ship coordinate X,Y *2
  4. Health *1
  5. Energy *1
  6. Torpedoes *1
  7. Cargo *16
    1. Type *1
    2. Qty *1

So how do you get this into and out of upper memory?

Let's allow for 48 bytes per object. If we have 8 objects per sector, we would use 384 bytes per sector. That doesn't evenly work out to 8K, so let's make it 16 sectors per 8K bank. 

With 64 sectors, that would be 4 banks. 

So to address a sector, we need S (sector), B (bank), P (start position), and (object Number in sector), and BS (bank size)

5000 REM GET UPPER MEMORY ADDRESS. S=SECTOR
5010 BS=16:OS=48
5020 P=S/BS:B=INT(P)
5030 P=P-B:P=P*BS
5040 B=B+1
5050 P=P*OS+$A000
5060 RETURN

if S=0 then P should be 40960.

Set S=1 and P should be 41008.

Set S=17 and B should be 2, and P should be 41008

 

First, we get the bank number by dividing by 16. (should be 1)

Then we multiply the remainder back out to get the offset within the bank.  (

Finally, the first bank is used by the KERNAL, so we need to add 1 to get the next free bank.

This assumes your sectors are numbered starting at 0, so: 

image.png.f01bd13d1331f815d172ca09e470e159.png

So....
17 is in in the second bank (B=2)
16 is the first block in bank 2, so 17 is the second. This is 48 bytes in. 
$A000 + 48 = 41008

 

At this point, you know the Bank number and Peek/Poke address of each object. 

So you'd read an object in like this:

2000 S=0:GOSUB 5000
2010 FOR I=0 TO 7
2020 POKE 0,1
2030 ST(I)=PEEK(P):P=P+1
2040 SN$(I)=""
2050 FOR J=1 TO 16
2060 SN$(I)=SN$(I)+CHR$(PEEK(P))
2070 P=P+1
2080 NEXT
2090 SX(I)=PEEK(P):P=P+1
2100 SY(I)=PEEK(P):P=P+1
2110 SH(I)=PEEK(P):P=P+1
2120 SE(I)=PEEK(P):P=P+1
2130 SM(I)=PEEK(P):P=P+1
2140 FOR J=0 TO 7
2150 SC(I,J)=PEEK(P):P=P+1
2160 SQ(I,J)=PEEK(P):P=P+1
2170 NEXT
2180 NEXT
 

Hopefully, we'll soon get improved BASIC commands to deal with transferring data into and out of banked memory. I created an enhancement request a while back for just this purpose:

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

With things like PEEK$, you could simplify the inner loop at 2050-2070 with SN$(I)=PEEK$(P)

I've attached a simple BASIC program that simply loads and reads a sector of space.

BANK4.PRG

Edited by TomXP411

Share this post


Link to post
Share on other sites
10 hours ago, Starsickle said:

If we had the X16 right now, I'd of course be using its own keyboard, and perhaps drivers for its own keyboard on a modern system.

The keyboard is simply a USB and PS/2 keyboard. You just plug it in to a PC and run the emulator, no special drivers needed.  🙂

 

  • Like 1

Share this post


Link to post
Share on other sites

@TomXP411 Thanks - I'm a bit groggy, but let's take a look:

For clarity, the special region is as posted above: 10x20 with 10x10 sectors. the real problem is storing the data associated with them either as tables or as the third index. I'm opting for the third index, but this DOES explode memory cost.

What you are proposing is pretty technical and I don't have much experience with it. I would prefer to wait for the keyword to be finished before hammering out functions to bitwise poke into the X16's novel memory banks.

Of course, I'd also ask for the interpreter to recognize the character format, as I'd be perfectly happy NOT wasting what seems to be the C64's method of allocating strings when I could just have characters.

That said - I could probably use some amount of banks for the 200 sectors. Sleepy-brain-without-coffee tells me that's quite a lot of contiguous memory, and I'm having a hard time visualizing where it's going because I've read some things.
http://microheaven.com/FastC64Basic/tips.html (ASIDE: "Don't do bubble sort" kinda tickles me)

For now, at least, I'm back up and running having cut (9,9,9) to (9,9,2) and (9,19,5) to (9,19,2). Unfortunately, I'd also like to add information to tag objects like planets or ships ownership, but alas - that requires an index or ID and another table, which is essentially the same problem but fractured. It's a design thing, so I'm just cutting things and returning to making the game be a working game for the time being. The good news is that the data as is now fits.

Edited by Starsickle
  • Like 1

Share this post


Link to post
Share on other sites

Rough day. Good news is that another Code Cleanup is complete, but the bad news is that I've reimplemented  Move, Warp, Scan, and Fire as far as I could take them - and was about to see how the Regional map printed out on generation but ran into the memory problem again.

I commended out Sector - expecting to use High Ram for that, later, but unfortunately - I was so close to finally getting a shot of the revealed map instead of ???? when I ran out of memory again - this time inside a lowly subroutine to print the bottom bar. Out of Memory again.

This cannot continue. I need a better way to store everything, or I need to find new ways to handle individual characters or not store as many strings.

Case in point - the way screens are drawn.

These are stored as strings. Strings that I really don't exactly know where on the X16 low memory they are stored on the stack or when they are garbaged. The top line is a 80 character string. The bottom three bars are 3 80 character strings. The title screen is therefore some amount of string descriptors and some amount of arrayed characters in the assigned memory space - resulting in about 4234 bytes, or otherwise 10% of our available memory space before whenever the garbage collector gets to remove the ones seen in the screen.

This is my best opportunity now to handle this without understanding how to write to a specific bank as easily as I write to wherever. I'm clearly at a stopping point, and I need to crunch my memory usage because what is currently allocated shouldn't be swapped out of memory unless I want a LOT of very interesting glitches or bugs to appear down the road or find some way to always safely process-out the swapping of banks between calls. It's time to stop coding and start reading, as the memory limit is preventing me from testing and making pushes forward.

RetroTrek-WIP16.png

Edited by Starsickle

Share this post


Link to post
Share on other sites
Quote

String storage in C64 BASIC

C64 BASIC uses 3 bytes for each string, which are stored in the 5 byte area of a simple variable located in the variable area or just takes exactly 3 bytes per element in case of a string array. This structure, called string descriptor, consists of one byte containing the length of the string (hence the maximum of 255 bytes) and of two bytes forming a pointer to where the string is kept on the string heap.

With statements such as, 10 A$="A STRING" or strings that are filled by a READ statement, the string descriptor points to program area where the statement is located so no space for the string itself has to be used. Other strings such as those built with an INPUT statement, returned by string functions or those created by joining two or more strings together are stored in the area of memory between the array area and the highest memory used by BASIC which is commonly known as the "string heap". The string pointer points to the start of this string.

Whenever a string that points to string heap is changed, its pointer is changed and the former string that was formerly referenced by this pointer is unused now on and becomes "garbage". To get the new string present on the string heap a new memory allocation will be made - even if the original string would be large enough to contain the new string. In case of statements like A$=B$ where B$ already points to the string heap then rather setting A$ to point to the same string, a new copy of B$ is created (as a result of the generalized expression evaluation) on the string heap where A$ will be pointing to.

https://www.c64-wiki.com/wiki/Garbage_Collection

Oddly enough - a potential answer in Garbage collection.

So, there is a solution here which might have diminishing returns very quickly. Every time I make a string in code, the descriptor points to the program, where it's already been stored. This gets large very quickly, but what I'm fuzzy on is - does it ever get UNallocated, for example, when exiting the scope of a GOSUB after RETURN by the garbage collector?

If it is, then the cost of pre-allocating often used strings is cheaper than defining them in the code (alike above). That is one direction I could take.

Sadly, I don't know what exactly I'm running out of - There are segments of memory dedicated to pointers and segments that contain their contents. Given the state of the program right now, I have have lot of strings defined in code.

What I think I need right now is a way to get the total size of a segment of memory (the string content, most likely) and give myself an in-game meter in order to watch.

In the midst of that little task -  uh oh:

RetroTrek-WIP17.png.45a01d1e61cf57d67bd836853fc120b5.png

EDIT 2:  ......................................Comments. The memory usage in a program includes the space taken by remarks. Wow. Just wow. After deleting some documentation, I was back under the limit and able to play. I have to delete and compress all of the comments in this file, and I know there are still thousands more lines to this program when it's done.

Well - that is pretty devastating. I'm not even a third of the way done.

EDIT3: Well, after some much-needed sleep - the answer lays within the ability to save program code space by swapping files and eliminating code from the main file to another file to be loaded and executed before popping back to the main loop. I know how to generally do this elsewhere, but not in BASIC V2 on the X16. How this is done without ruining the process or the program counter and making it as easy as functional programming - well - it feels a bit out of my league right now, but I'm not going to wimp out. I just need to understand how it's done cleanly within the loop of DRAW, INPUT, UPDATE, and returning to the main screen so the user can play.

I could use an example game that is using multiple files to manage its game state like this and how I could package it on a file system.

Edited by Starsickle
Sleep and breakthrough.

Share this post


Link to post
Share on other sites

At this point, I've hit the memory ceiling and cannot code further unless I solved this problem.

The program is too big. The best thing to do is to LOAD and RUN a separate program and RESUME where the program left off when the subprogram finishes executing. This is not something I know how to do in BASIC V2, though it was easier to solve in SMILEBasic, where I had 6 file slots and would run the main loop in 1, data and core in 2, Map and Input in 3, and Content loading and swapping in 4 and 5. If I understood the code necessary to do this in this language, I could do this. I'm not a stranger to The Game State Machine.

But, it seems my general design in this one-file-wonder that takes place mostly on a single screen is going to have a lot of trouble, as the game never really changes state. How do I save the most code space loaded into memory for execution and smoothly drop into and out of subprograms? I definitely could use some wisdom and instruction on this.

Currently, the one-file-wonder is organized as so:

Quote

LINE NUMBERS:

    - 0 series    - Boilerplate, Common, and Core Program.
    - 1000 series     - Common, and Core Program.
    - 2000 series     - For Main Loop and Graphical/Text Functions/Subs
    - 3000 series     - For all GUI and Screen Functions/Subs
    - 4000 series     - Ship Systems Implementation
    - 5000 series     - RESERVED - COMBAT AND TURN MECHANICS
    - 6000 series     -
    - 7000 series     - Map Handling Subroutines.
    - 8000 series     -
    - 9000 series     - IN FLUX
    - 10000 series     - Command Implementations
    - 20000 series     - RESERVED FOR STRING AND TEXT CONTENT
    - 30000 series  - Termination and Error Handling.
    - 40000 series  - Data Tables

The current tasking for this involves removing the 3000 series screens, since they are entirely separate screens and terminating game screens. This would similarly be done with anything currently occupying blocks that are just static data initialization. Sadly, I don't know if I could get away with it, since it DOES mean all that program still needs to be loaded into the precious Low Memory.

A more elegant design might have me able to take the longest Subroutines and create them as programs - effectively turning a loader into the equivalent to a GOSUB. That would be best. This means I have unlimited power on the filesystem, since our filesystem has no conceivable limit in size other than the media.

I am not experienced enough to really understand good, clean, organized design on this platform, so at this point I could use some wisdom and examples. In the meantime, I pitter away at small tasks and spend time cleaning code in preparation. I want a 0-1999 Segment that I can copy paste into anything, and I'm fairly close to having that complete as soon as a few more code cleanups are finished.

Share this post


Link to post
Share on other sites

I had this problem with my Traveller Trader game -- the star chart just takes up too much space.

The solution is to shove it into a high RAM bank.  I'm slowly working on that.

 

Share this post


Link to post
Share on other sites

You will probably need to move all your data (text and otherwise) to banked RAM. You can put it in a separate file that is loaded straight into banked RAM, which can be done at the beginning of your program. That way, your BASIC program is mostly code.

  • Like 1

Share this post


Link to post
Share on other sites
On 9/14/2020 at 8:43 PM, SlithyMatt said:

You will probably need to move all your data (text and otherwise) to banked RAM. You can put it in a separate file that is loaded straight into banked RAM, which can be done at the beginning of your program. That way, your BASIC program is mostly code.

Matt's right.  Your main program can start with something like 

10 poke $9f61,1 :rem point to RAM bank 1
20 load "screendata.bin",8,1,$a000 :rem load screen data
30 poke $9f61,8 :rem point to RAM bank 8
40 load "mapdata.bin",8,1,$a000 :rem load the map
	

Apparently, if the file is larger than 8K, then the loader will simply move to the next bank.  So you could load your entire map into banked RAM with one load.

 

Edited by rje

Share this post


Link to post
Share on other sites

When I was storing ship definition data in BASIC, I would store them in strings that looked like data structures (but of course weren't):

rem -------------------------------------------
rem QSP + strength + cargo + alignment + name
rem -------------------------------------------
dim qs$(17)
qs$(0)=  "S-AL222  3IMURPHY"
qs$(1)=  "S-AA223  5ISERPENT"
qs$(2)=  "J-AL222 20 ASAR"
qs$(3)=  "A-BS111 80 BEOWULF"
qs$(4)=  "A-BS121 60 MARAVA"
qs$(5)=  "K-BA122  6 TARKINE"
qs$(6)=  "Y-BS121 20 BAKAAL"
qs$(7)=  "P-DA643 40*AZ ALRRAK"
qs$(8)=  "R-DA111200 MARCH"
qs$(9)=  "G-DL713 10AKHOSAA"
qs$(10)= "E-DU523  2IGAZELLE"
qs$(11)= "M-FU131120 BRILLIANCE"
qs$(12)= "E-FS413 24ZSESAVETL"
qs$(13)= "G-FU423  3ZSHIVVA"
qs$(14)= "C-HU333 85 BROADSWORD"
qs$(15)= "G-HS443 30VSE KOEZ"
qs$(16)= "F-KS131400 SUSA"
qs$(17)= "R-TB432250 LEVIATHAN"

So for example, when a Type 17 ship was encountered, I'd find its definition in this table, and extract the fields using left$(), right$(), mid$(), and val().  It's name ("Leviathan") is stored at mid$(qs$(17),12), for example.

It's really rough on the heap, I suppose.

 

Edited by rje

Share this post


Link to post
Share on other sites
52 minutes ago, rje said:

Matt's right.  Your main program can start with something like 


10 poke $9f61,1 :rem point to RAM bank 1
20 load "screendata.bin",8,1,$a000 :rem load screen data
30 poke $9f61,8 :rem point to RAM bank 8
40 load "mapdata.bin",8,1,$a000 :rem load the map
	

Apparently, if the file is larger than 8K, then the loader will simply move to the next bank.  So you could load your entire map into banked RAM with one load.

 

Actually, it's even easier. You can just use the third argument to LOAD to specify the starting bank:

Quote

10 LOAD "SCREENDATA.BIN",8,1,$A000

20 LOAD "MAPDATA.BIN",8,8,$A000

 

  • Like 1

Share this post


Link to post
Share on other sites

Okay - so this is basically LOAD "FILE", DEVICE, BANK, ????

And - to close that circle - how do you access things that you put in that bank? (I have a feeling my question thread now contains this - just humor me)

If I can get this understood and successfully demoed for myself, I can redesign the program and REALLY have some room to work with, as well as organize the code much better with full documentation. I'm not used to being so formally punished for doing (what I consider to be) a good job! XD

Share this post


Link to post
Share on other sites
25 minutes ago, Starsickle said:

Okay - so this is basically LOAD "FILE", DEVICE, BANK, ????

Yep, that's it.

25 minutes ago, Starsickle said:

And - to close that circle - how do you access things that you put in that bank? (I have a feeling my question thread now contains this - just humor me)

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use