XB loader

[Asmusr]

Can anyone help me writing an XB loader for my assembly game? It has to be loaded into high memory AORG >A000 -> D8C6. I tried to use SYSTEX, but it crashes. Thanks.

[RXB]

My RXB game IN THE DARK used >C000 as the area to load my Assembly, but >B000 would also work. I would not recommend >A000 as sometimes buffers stuff is there.

 

Get a copy of IN THE DARK and run it from Classic99 to see how it works.

 

http://atariage.com/forums/topic/213441-rxb-sams-game-in-the-dark/page__st__25

[Willsy]

Tursi and I worked on a loader for Bill Sullivan back in 2009 (I think). It was for TI basic but we could probably convert it to run on xb with s little effort.

 

I'll dig out the source tomorrow, unless you can locate it on this forum somewhere.

 

Mark

[Asmusr]

Tursi and I worked on a loader for Bill Sullivan back in 2009 (I think). It was for TI basic but we could probably convert it to run on xb with s little effort.

 

I'll dig out the source tomorrow, unless you can locate it on this forum somewhere.

 

Mark

 

Great, thanks.

 

Rich: it has to run at >A000. It uses all available memory - also >2000->4000 as buffers.

[RXB]

Great, thanks.

 

Rich: it has to run at >A000. It uses all available memory - also >2000->4000 as buffers.

 

Is it a XB game or a Assembly game?

Like my IN THE DARK is both?

 

I still need to release the 960K version of IN THE DARK that uses a 1024K AMS card.

[sometimes99er]

Correct me if I'm wrong.

 

Rasmus is asking about XB.

 

IN THE DARK is RXB only.

 

Most people with the real deal have XB and not RXB.

 

[RXB]

RXB is on Classic99 and a few cart or GRAM devices are out there. So not quite as barren as you make it out to be.

Besides what I did with RXB can be down with XB but you just need more memory to make it work with a CALL LINK.

Also I used the SAMS that also is a better concept then a 32K and they are out there, also on emulators.

 

If people are going to make the argument that the hardware is rare then why not just go Console only and no cart?

 

I used Assembly and XB but accessed it with RXB, it could be done with normal XB but would take a hell of alot more effort and complications.

[sometimes99er]

RXB is on Classic99 and a few cart or GRAM devices are out there. So not quite as barren as you make it out to be.

 

Hmm, I was talking about the real deal, not Classic99, and thought I wouldn't go wrong with "Most people" ...

 

 

If people are going to make the argument that the hardware is rare then why not just go Console only and no cart?

 

Quite a few XB carts are out there. Not quite as barren as you obviously would like it to be.

 

 

I used Assembly and XB but accessed it with RXB, it could be done with normal XB but would take a hell of alot more effort and complications.

 

Well, people are people, and I would certainly be able to do something quicker with Assembly and XB instead of RXB. Simple as that. Much like I'm writing faster in Danish than in English. Like I know Assembly better than GPL. So in my world Assembly is a hell of alot faster than GPL.

 

Edited August 10, 2013 by sometimes99er

[RXB]

 

Quite a few XB carts are out there. Not quite as barren as you obviously would like it to be.

 

 

I was just pointing out the argument was to be a purist and I never buy into that stuff.

Purism is just pigheadedness and rejection of anything new. Or rejection of anything not of your own interests.

 

Besides I did say it could be done with normal XB, but one hell of alot harder to pull off.

The Source Code could be used in normal XB and you can do a (RXB) EXECUTE in normal XB just like RXB as I got the idea for it from Micropendium in the first place.

I would have to look it up but even Bruce Harrison mention it at one time.

[Asmusr]

To return to my original question, the game is now available in the Titanium thread but without an XB loader.

[sometimes99er]

I was just pointing out the argument was to be a purist and I never buy into that stuff.

Purism is just pigheadedness and rejection of anything new. Or rejection of anything not of your own interests.

 

Besides I did say it could be done with normal XB, but one hell of alot harder to pull off.

The Source Code could be used in normal XB and you can do a (RXB) EXECUTE in normal XB just like RXB as I got the idea for it from Micropendium in the first place.

I would have to look it up but even Bruce Harrison mention it at one time.

 

I understood that Rasmus experienced the Smooth scrolling to run smoother on the real deal and also wanted to support or utilize the F18A. Obviously wanting to support what's out there - both real and emulation - no purist stuff there as I see it. RXB into that equation would not help -> emu and limited iron. Suggesting to keep RXB out of the equation is perhaps being a bit of a purist.

 

Why use Extended Basic to draw Alfred flying around in space when you can use a digitizer - it's so much faster. Just me rambling and grasping at straws.

 

[RXB]

I understood that Rasmus experienced the Smooth scrolling to run smoother on the real deal and also wanted to support or utilize the F18A. Obviously wanting to support what's out there - both real and emulation - no purist stuff there as I see it. RXB into that equation would not help -> emu and limited iron. Suggesting to keep RXB out of the equation is perhaps being a bit of a purist.

 

Why use Extended Basic to draw Alfred flying around in space when you can use a digitizer - it's so much faster. Just me rambling and grasping at straws.

 

 

I do things in RXB in ways no one has ever thought of before. I tend to think outside the box more then others.

 

Great ideas are usually from left field and not have direct correlations with the original plan.

 

Think Microwaves ovens, they were not the original concept it was a accident and water in a human body.

Edited August 10, 2013 by RXB

[sometimes99er]

I do things in RXB in ways no one has ever thought of before. I tend to think outside the box more then others.

 

Great ideas are usually from left field and not have direct correlations with the original plan.

 

Think Microwaves ovens, they were not the original concept it was a accident and water in a human body.

 

Oh, I see.

[Asmusr]

Sometimes is right that I'm looking for a solution that works on my real console. I have 2 XB carts but unfortunately no RXB cart.

 

[Edit] I should perhaps clarify that I just need to load the code at >A000 and run it. I don't need to return to basic later and I don't need to load or call any console routines.

[senior_falcon]

Does Titanium rely on the E/A utilities or are they part of the program? What about VDP registers - does it set them when it starts or does it use the default ones provided by the E/A cartridge?

[+InsaneMultitasker]

Tursi and I worked on a loader for Bill Sullivan back in 2009 (I think). It was for TI basic but we could probably convert it to run on xb with s little effort.

 

I'll dig out the source tomorrow, unless you can locate it on this forum somewhere.

 

Mark

I believe the final version of the loader is located in the SWPB forum's file section. I recall uploading a fix or two to the code, called PADLOADER (or similar) as part of your efforts.

 

There was also a DSRLNK thread where Paolo and others worked on an improved DSRLNK that could report errors for both >8 and >A DSR calls. Version 3.0 rings a bell.

 

YLOAD is an oft-used XB Loader that can be found in various disk images. I believe the AtariSoft game disk had this routine on disk as an EA3 DF80 format.

[+InsaneMultitasker]

*forum locked while posting and duplicated the response. Deleting duplicate*

Edited August 10, 2013 by InsaneMultitasker

[+InsaneMultitasker]

Can anyone help me writing an XB loader for my assembly game? It has to be loaded into high memory AORG >A000 -> D8C6. I tried to use SYSTEX, but it crashes. Thanks.

 

The attached loader is an oldie but a goodie. I use it for my EA5 game disks. It is really just a spruced-up EA5 loader that runs from XB.

 

Titanium seemed to load and run fine under Classic99 using this loader from XB.

 

1. The file is TIFILEs format. Remove the .ZIP extension after downloading.

2. The loader only works with 4 character files. So rename TITANIUM to TITA, TITANIUN to TITB.

3. The name/title is in line 344.

LOADT.ZIP

Edited August 10, 2013 by InsaneMultitasker

[Asmusr]

Titanium seemed to load and run fine under Classic99 using this loader from XB.

Thank you, yes it's working fine, and so much faster than loading the object file using call load.

I noticed this is also somehow based on SysTex, but perhaps only to load the loader?

[Omega-TI]

It also works fine under Extended BASIC using the BOOT program. It's kind of nice to have it in with all the other best-of-the-best games under one menu in a single disk/volume.

 

I nominate your program as the BEST NEW GAME PROGRAM OF 2013

[RXB]

Sometimes is right that I'm looking for a solution that works on my real console. I have 2 XB carts but unfortunately no RXB cart.

 

[Edit] I should perhaps clarify that I just need to load the code at >A000 and run it. I don't need to return to basic later and I don't need to load or call any console routines.

 

There are several ways to do that.

1. CALL LOAD

2. Dinky Assembly that moves the code, like put the code in after REM statements or ! then extract the code and move it.

3. Make a custom loader from disk and a dinky assembly mover from VDP to RAM.

4. Systex or similar programs.

 

I have written programs to do all of these at one time. In XB before I created RXB.

[+InsaneMultitasker]

[/size]

Thank you, yes it's working fine, and so much faster than loading the object file using call load.

I noticed this is also somehow based on SysTex, but perhaps only to load the loader?

Correct. Most of the loaders called from XB are fairly simple in that the filename is passed to the loader; its job is then to load the files, determine where the file data should be copied within CPU RAM (32K), and set up the VDP environment similar to what the E/A cart sets up. There isn't much more to it. Smart loaders can relocate themselves to scratchpad to avoid being overwritten but most reside (and stay) in the lower 8K space from 0x2000-0x3fff.

 

Systex and similar programs embed assembly that is relocatable within the lower 8K space. This is why Systex failed to work with your game program.

 

Update: You could pare down the loader by deleting all the code related to the menu and selections, forcing load from disk very easily. As I mentioned there are other loaders out there that will take a longer pathname and may be better suited for you.

Edited August 11, 2013 by InsaneMultitasker

[Willsy]

Ah, nice one, Tim!

 

Here's the one we did a few years ago anyway. It's designed to take a filename from a CALL LINK in TIB but that could soon be stripped out.

 

REF DSRLNK,STRREF,VMBR,VMBW,VWTR,GPLLNK
DEF OPT5

VDPADR EQU >1000	 address to load the file(s) in vdp ram
VDPPAB EQU VDPADR-26 address of the pab in vdp ram
OPLOAD EQU >0500	 opcode for load operation for dsrlnk
WS	 EQU >20BA	 workspace >20ba (ed/as pg.246)
FAC	 EQU >834A

* sit at the end of ram out of the way :-)
 AORG >FF08

* get the file name from call link statement
OPT5
LIMI 0
LWPI WS	 set workspace
CLR R7		 program start address
CLR R0		 not an array element
LI R1,1	 first parameter
LI R2,PAB+9 address of buffer to place the string
BLWP @STRREF get string from call link

* now place the pab in vdp ram
DOLOAD
LI R0,VDPPAB vdp ram address
LI R1,PAB	 source address
LI R2,26	 copy 26 bytes
BLWP @VMBW	 write to vdp ram

* load address >8356 with address of length byte
LI R0,VDPPAB+9 address of length byte of pab in vdp ram
MOV R0,@>8356 move it to >8356

* call the loader
BLWP @DSRLNK load the memory image from device
DATA 8		 ed/as section 16.2.4 (page 262)

* the file should now be in vdp ram at address vdpadr onwards

* get the first three words of data from vdp, which tell us
* how to handle the data
* word 0 (r3)=eof file indicator (0=no more files to load)
* word 1 (r4)=length of data in bytes
* word 2 (r5)=destination address in cpu ram
* we'll read them directly into registers, just to be clever :-)
LI R0,VDPADR address of first byte of loaded data
LI R1,WS+6	 point to r3 :-)
LI R2,6	 6 bytes to read
BLWP @VMBR	 get the data

* examine first word of the data
* if equal to 0 then no more loads required
MOV R3,R3	 test first word
JEQ NOMORE	 if 0 no more files required
SETO R6	 else more files are required. set flag
JMP NEXT	 skip to next section
NOMORE
CLR R6		 no more files are required. clear flag

* we now have all the info we need to copy the loaded data to
* cpu ram
NEXT
MOV R7,R7	 are we loading the *first* file?
JNE SKIP	 skip if not
MOV R5,R7	 save the launch address of the program
SKIP
LI R0,VDPADR+6 address of first byte of the actual program in vdp
MOV R4,R2	 number of bytes to copy
MOV R5,R1	 destination address in cpu ram
BLWP @VMBR	 copy from vdp to cpu ram

* see if any more files are required
MOV R6,R6	 check flag
JEQ LAUNCH	 if 0 then launch program

* else more files are required
* increment the last character of the filename
CLR R1		 prepare r1 for byte operations
LI R0,PAB+10 address of start of filename
MOVB @PAB+9,R1 length byte in msb
SWPB R1	 rotate into lsb
A R1,R0	 add length to address. now pointing at last character+1
DEC R0		 now pointing at last character
MOVB *R0,R1 get the last character in r1 msb
AI R1,>0100 increment by one
MOVB R1,*R0 put the new character back in pab
JMP DOLOAD	 load the next section

* set up editor assembler environment and launch program
LAUNCH
LI R1,EAREGS address of register data
LI R2,8	 8 bytes to write
CLR R0		 vdp register
NXTREG
MOVB *R1+,R0 get a byte from the list
SWPB R0	 rotate register value into lsb
BLWP @VWTR	 write to vdp register
AI R0,>0100 next register
SWPB R0	 get reg value in msb
DEC R2		 finished?
JNE NXTREG	 loop if not
MOVB @EAREGS+1,@>83D4 copy vdp r1 to >83d4
LI R0,CHRADR point to list of vdp addresses
MOV *R0+,@FAC vdp address for small capitals
BLWP @GPLLNK load small capitals character set
DATA >0018	 gpl command code
MOV *R0+,@FAC vdp address for lower case
BLWP @GPLLNK load lower case character set
DATA >004A	 gpl command code
MOV *R0+,@FAC vdp address for large characters
BLWP @GPLLNK load large character sets
DATA >0016	 gpl command code
MOV R7,@>83E0 start address in R0 of GPLWS
LWPI >83E0 load GPLWS
B *R0 launch the loaded program

EAREGS
DATA >00E0,>000E,>0106,>00F5 vdp register values
CHRADR
DATA >0900,>0B00,>0C00		 vdp char set addresses

PAB
DATA OPLOAD opcode for load
DATA VDPADR destination address in vdp
DATA >0000	 not required for load operation
DATA 8198	 max number of bytes to load (8192 + 6 bytes header)
DATA >000F	 last byte=length byte
BSS 16		 buffer to hold filename

END

loader.txt

[RXB]

So this only handles pathnames 26 characters long?

 

DSK.VOLUMENAME.PROGRMNAME

 

Something like Hard drive paths will not work.

 

SCS.ASSMGAMES.JOYSTGAMES.PRGRMNAME

 

Of course not everyone has a hard drive but a 80 character buffer instead would be nice.

[senior_falcon]

The loaders being discussed above are designed to load and run EA5 files out of XB. This is a more or less universal way to run an assembly program out of XB, and it is probably the easiest way.

 

There is another way that was hinted at by Rich which embeds the program in an XB program. After saving, the program can be loaded and run just like an XB program, but all it does is move the assembly program to the desired location and then start it up. SYSTEX is one example of this. But this technique does not limited you to transferring assembly routines into low memory. You could move the assembly program from >A000 into a buffer, add a few lines of XB code and save it as an XB program. If anyone is interested in this type of loader, I will have a little time tonight and could outline the general principals that you need to know and provide the source code for a SYSTEX like loader. With a few modifications this could be made to do what you want.