Commander X16

19 minutes ago, TomXP411 said:

You have to mount an image file. The emulator cannot write directly to the file system. (I suspect that for saving to the host file system, the emulator traps LOADs and SAVEs without a device number, rather than emulating a disk drive.)

You don't have to mount an image file, unless you want to test the actual SD Interface code in the Kernal. For the emulator, it indeed traps LOAD and SAVE calls and just does native fopen/fread/fwrite calls to interface with the host file system, if no SD card image is specified. However, you do need to specify device 8 for this work, and SAVE definitely writes out to the host file system correctly, as long as the segment of RAM you are writing out is in low RAM ($0000 to $9EFF) and not banked memory.

It traps LOAD and SAVE just fine, but I do think Tom's right that I need to mount the SD image before manipulating SEQ files.

 

12 minutes ago, SlithyMatt said:

You don't have to mount an image file, unless you want to test the actual SD Interface code in the Kernal. For the emulator, it indeed traps LOAD and SAVE calls and just does native fopen/fread/fwrite calls to interface with the host file system, if no SD card image is specified. However, you do need to specify device 8 for this work, and SAVE definitely writes out to the host file system correctly, as long as the segment of RAM you are writing out is in low RAM ($0000 to $9EFF) and not banked memory.

I was talking about reading and writing sequential files, which is why I talked about OPEN, INPUT#, etc.

Currently, using INPUT# with sequential files is much faster than LOADing to upper memory and then using PEEK and POKE loops.  I don't recommend using disk files to buffer dynamic game data, however, since every write to SD reduces its endurance. So for stuff that's changing over time, use upper memory. For stuff that's static, just re-read from storage as needed.

 

1 minute ago, TomXP411 said:

You completely missed the point... this was about reading and writing sequential files, not using LOAD and SAVE. 



 

Sorry, too much crosstalk. Definitely, fast-changing data should be kept in RAM and not paged out all the time to "disk". I'm not sure what the point of SEQ files is with the X16, as that seems to be a Commodore-specific approach borne of the limitations of the era.

15 minutes ago, SlithyMatt said:

Sorry, too much crosstalk. Definitely, fast-changing data should be kept in RAM and not paged out all the time to "disk". I'm not sure what the point of SEQ files is with the X16, as that seems to be a Commodore-specific approach borne of the limitations of the era.

I'd actually been wondering if the RAM banks could be abstractly treated as a device, with secondary numbers 0-255 representing bank numbers, thereby allowing transfer via INPUT# and PRINT#...  yeah it's clunky.

Devices 8-15 are all "disk drives" and 16-30 are "unknown".  They're assumed to be on the serial port, but MUST they be?

Suppose device 16 represents the RAM banks and device 17 represents the ROM banks.

1 OPEN 1,16,2,"0:DUMMY STRING,S,R".  :rem read from device 16 (RAM Bank) #2 (Bank 2).  Ugly!!

2 INPUT#1, A$, B, C$, D%, E$, F$

3 CLOSE 1

It treats each bank as a SEQ file, kinda.  Yeah it's ugly.  Supa-ugly.  And there are questions in my mind about how to issue commands.  But... it might could let us drag typed data in and out of RAM banks.

 

This gets into the associative arrays discussion from 2019. It's pretty clean to have a RAM disk on a specific device number, but for best utility it should emulate a drive. Typically we can equate file# and secondary address#, as for reading and writing sequentially they have to be between 2 and 14 and have to be unique, so the access to the RAM disk should permit that. We already have the vectored hooks for the device# I/O, so it can be prototyped as a Golden RAM ($400-$7FF) utility and if it works out, we could look at packaging it for addition to the Kernel.

As a RAM disk, we have a lot of flexibility about set up information, because that can be in the commands that can be sent to the pseudo disk drive, so there is no need to strain to get information into the dev#, file#, sa# data.

There is a very strong case to have the routines that OPERATE the a HighRAM RAMdisk in FlashROM somewhere, because placing it in High RAM requires a lot of trampolining, which would slow it down substantially, while LowRAM is quite scarce relative to HighRAM OR FlashROM.

 

19 hours ago, BruceMcF said:

It's pretty clean to have a RAM disk on a specific device number, but for best utility it should emulate a drive.

That's pretty clever...

Back to important things, i.e. RETROTREK (hey, I like all caps instead of partial caps... but that's just me).

For your edification, here is code I wrote that reads data loaded into RAM Bank 1.  I LIKE having data in the RAM banks because it can be packed in very efficiently, as opposed to BASIC floating point numbers.  I dislike it because of the PEEKing I have to do, but I can work with that.

Anyway, here's the BASIC code, and the binary file it loads and reads from.  MAYBE this could help you with a plan of attack.

 

ALLSHIPS.BIN shipbrowser.bas

I'm looking it over - the hardest part of all this really is that everything is in 2 letter variable names - but I can see you start at the starting address (AD) and allocate a specific amount of bytes to the name (24).

First poke unknown - assuming it's a sentinel value or some other control value.

Next is the quick ship profile, which is a Single character Archetype with 5 characters (uhh, a few have 6...). This is pretty slick, as it can be used for more procedural generation and representation.

After that we're jumping around a bit, but CHR$(48+X) I assume is just navigating the character Table. Otherwise everything is a record of N size, controlled by LN for the line, jumping to a new AD because you know the size of each record in terms of characters and integers.

If you don't mind, I'd like to try my hand of recombobulating this so I can store my own ship information, which currently looks like so:

41100 REM //SUBROUTINE - STARSHIP NAMES AND IFFS - ===========TODO - MOVVVEEEEEE
41101 SID$(0,0) = "ENDEAVOR" : SID$(0,1)="ALLI"
41102 SID$(1,0) = "NME-1" : SID$(1,1)="KLRG"
41103 SID$(2,0) = "NME-2" : SID$(2,1)="KLRG"
41104 SID$(3,0) = "NME-3" : SID$(3,1)="KLRG"
41105 SID$(4,0) = "NME-4" : SID$(4,1)="KLRG"
41106 SID$(5,0) = "NME-5" : SID$(5,1)="KLRG"
41107 SID$(6,0) = "NME-6" : SID$(6,1)="KLRG"
41108 SID$(7,0) = "ASTORIA" : SID$(7,1)="ALLI"
41109 SID$(8,0) = "RET-1" : SID$(8,1)="INDA"
41110 SID$(9,0) = "MERCH-1" : SID$(9,1)="DORA"
41111 RETURN
	41120 REM //SUBROUTINE - SHIP DATA DEFINITION - SEE README  ================
41121 DATA 3, 3, 90, 3000,   18, 0, 300,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41122 DATA 1, 1, 30, 1000,   6,  0, 100,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41123 DATA 2, 2, 60, 2000,   12, 0, 200,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41124 DATA 3, 3, 90, 3000,   18, 0, 300,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41125 DATA 1, 1, 30, 1000,   6,  0, 300,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41126 DATA 2, 2, 60, 2000,   12, 0, 200,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41127 DATA 3, 3, 90, 3000,   18, 0, 300,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41128 DATA 3, 3, 90, 3000,   18, 0, 300,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41129 DATA 2, 2, 60, 2000,   6,  0, 200,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41130 DATA 1, 1, 30, 1000,   6,  0, 100,   6, 6, 6, 6, 6,   0, 0, 0, 0, 0
41131 RETURN

If I learn how to do this (and make it work), I definitely could just throw all the object data in the game into segments of a 512k High Ram Bank. Reading sequentially is a pain and N data lines grows, but perhaps, in known and well-defined cases, an ID can be assigned that matches a memory address for direct access, sorting, etc?

Would love to have this sort of layout with the ability to highlight and select a line by inverting the color of the currently selected line. This is why I have colors set in variables along with their inversions.

 

This is what I'm considering for the main file, although there's some concerns with how this will work.

15 MC%=0 : REM //THE MASTER COUNTER - USED FOR PROGRAM JUMPING.
16 LS%=0 : REM //LOADED FILE STATE - CONTROLLING THE LOADED FILE.

19 REM // DEPENDING ON GAME STATE: INIT DATA, MAIN LOOP, EXTRA, TERMINATE
20 ON LS% GOSUB 28,1000,1000
	

The Master Counter will increment every time a file is jumped. This will help me determine if the program is functioning properly. It's not needed, as I originally thought I could use MC to control or save a line number.

The Loaded File State is the important one. This determines the program state, and when any given program file is loaded for execution into Low RAM, it HAS to hit a check versus the state first.

So - what's wrong? The fact they are defined above. I think I could move those down into GOSUB 28 (which is implicitly LS%=0, right?), but now the problem exists of the following:

A lot of this program is broken up into subroutine pieces and helpers. If I overwrite the program every time I load a new file, I have to make sure I make several pieces redundant, or only include them within the file loaded for execution. This is very big design challenge, because one has to remember not to overwrite important pieces of data that remain in the appropriate Low RAM stack.

Outside of that challenge? Well, there is an alternative, but I don't think it's possible - I could load the program entirely into High RAM, but I don't think it's executable from that area, as it's simply not segmented like the Low RAM. This would be an interesting ability, though.

 

EDIT: I also am not sure about how to capitalize the title - feel free to choose between RETROTrek, RetroTrek, and RETROTREK.