Geneve Questions!

[+arcadeshopper]

50 minutes ago, InsaneMultitasker said:

Does the program (in your case, YAPP) work with EXEC without /r?  Some programs require the BASIC GROMs or specific bytes in the TI ROM,  and therefore must be run from the GPL program.  

 

Secondly, I implemented the "/r" option with the HFDC and SCSI in mind and IIRC it only does a power-up of the HFDC. This leads to some quirky behavior at times and is different from GPL where the TI ROM powers up all devices.  Neither case should be an issue for TIPI since the Geneve EPROM performs a full-blown powerup of all devices on powerup. 

 

Edit: Only the later version of EXEC has the /r option so be sure you are using the right one. 

YMMV but yes rompage will get you access to TIPI. and DSK0-4 Mappings..  HOWEVER the program has to use DSR access. some wrote their own file access routines and they may ignore the DSR.

 

I'll do some testing later and make a video

Greg

[GDMike]

Greg, could you include showing other geneve products if you have time?

Thx

[+arcadeshopper]

Just now, GDMike said:

Greg, could you include showing other geneve products if you have time?

Thx

I have a few already if you look at my channel but yes I'll do more as time permits. https://www.youtube.com/c/arcadeshopper/

 

Greg

[+arcadeshopper]

 

there you are.. with actual fan and hard disk noises

 

[Nick99]

2 hours ago, InsaneMultitasker said:

Does the program (in your case, YAPP) work with EXEC without /r?  Some programs require the BASIC GROMs or specific bytes in the TI ROM,  and therefore must be run from the GPL program.  

 

Secondly, I implemented the "/r" option with the HFDC and SCSI in mind and IIRC it only does a power-up of the HFDC. This leads to some quirky behavior at times and is different from GPL where the TI ROM powers up all devices.  Neither case should be an issue for TIPI since the Geneve EPROM performs a full-blown powerup of all devices on powerup. 

 

Edit: Only the later version of EXEC has the /r option so be sure you are using the right one. 

Thanks!

I start YAPP with EXEC, have never known of /r, may be that I have an old version of EXEC... or it´s highly likely that it´s an old version.

[+InsaneMultitasker]

48 minutes ago, Nick99 said:

Thanks!

I start YAPP with EXEC, have never known of /r, may be that I have an old version of EXEC... or it´s highly likely that it´s an old version.

Run EXEC without any filename or parameters and it should tell you the version.  1.3 doesn't have /r. 

 

1 hour ago, arcadeshopper said:

with actual fan and hard disk noises

music to our ears

[+arcadeshopper]

4 hours ago, InsaneMultitasker said:

Does the program (in your case, YAPP) work with EXEC without /r?  Some programs require the BASIC GROMs or specific bytes in the TI ROM,  and therefore must be run from the GPL program.  

 

Secondly, I implemented the "/r" option with the HFDC and SCSI in mind and IIRC it only does a power-up of the HFDC. This leads to some quirky behavior at times and is different from GPL where the TI ROM powers up all devices.  Neither case should be an issue for TIPI since the Geneve EPROM performs a full-blown powerup of all devices on powerup. 

 

Edit: Only the later version of EXEC has the /r option so be sure you are using the right one. 

 

YAPP works fine without /r it just won't see any TIPI. drives.. 

[+FarmerPotato]

On 10/28/2020 at 8:00 PM, TheBF said:

Cool so one could do 

A:>EXEC DSK2.CAMEL99  

 

Is there a technical document on how to write programs for MDOS ?

My cross-compiler has a 64K segment reserved for the target program.  I could make a very FAT Forth system for Geneve. (not that many would care)  

 

 

I would care about Camel99!

 

 

I was just finding the GenProg documentation here: http://ftp.whtech.com/Geneve/mdos/MDOS Development documents/

For instance, this MDOS reference (it is kind of dated) and the collection of API calls documents. Manuals for GENASM and so on.

 

From memory... I can convey to you that it's a breeze to build a MDOS native program with GenProg. Especially if your code is self-contained (no assumptions about E/A or console ROM). 

 

The source should just use RORG. Assume you have 59K. Your address space is >0400 to >F000. You can put workspace in F000-F07E. F1xx-FFF9 is available.

 

You write a makefile and invoke it with MAKE.

In the makefile, you call ASM to produce object file(s). Then you call LINK to produce an executable.

GENLINK has its own control file, listing the input, output, and special directives. It can do quite a lot, besides making one big executable. (for instance, overlays.)

 

The specific things you'll have to replace with API calls are:

1. Keyboard scan
2. DSR access.
3. VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc.
4. Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API.
5. Allocating and mapping memory pages to fill the space above your program

 

If your Camel99 build system outputs object or binary on its own, you could make that work, too.

 

 

[+FarmerPotato]

On 10/28/2020 at 4:25 PM, BeeryMiller said:

There was also McCann Software Forth for the Geneve.  Several commercial applications were written by Mike for the Geneve including The Printer's Apprentice (TPA), and The Geometer's Apprentice (TGA).  There may have been some fonts that went along TPA.

Beery

 

What has been done to preserve commercial applications?  I realize some folks will treat things as abandonware, while others will not copy them. Another route is to track down the authors again.

 

But I would really like to see these McCann products--I had only seen the illustrated full-page ads in MICROpendium.

 

[+9640News]

2 hours ago, FarmerPotato said:

What has been done to preserve commercial applications?  I realize some folks will treat things as abandonware, while others will not copy them. Another route is to track down the authors again.

 

But I would really like to see these McCann products--I had only seen the illustrated full-page ads in MICROpendium.

 

Mike's Forth program for MDOS is up on whtech in the Geneve area.  I haven't looked for his The Geometer's Apprentice (TGA) or The Printer's Apprentice (TPA) he wrote for MDOS forth that are self execution programs to know if they are on whtech or not.  I've got those disks myself, along with some font disks for TPA I saw the other day.  I've tried finding Mike McCann, but have no idea what happened to him.

 

As far as other commercial programs for MDOS, Bruce Hellstrom's Mouse Driver package is or at least should be, on Whtech.  With Al Beard's Fortran package, and a few games for Abasic, I think everything commercial is out there on whtech including the GenProg package.

 

Beery

 

[+TheBF]

10 hours ago, FarmerPotato said:

I would care about Camel99!

 

 

I was just finding the GenProg documentation here: http://ftp.whtech.com/Geneve/mdos/MDOS Development documents/

For instance, this MDOS reference (it is kind of dated) and the collection of API calls documents. Manuals for GENASM and so on.

 

From memory... I can convey to you that it's a breeze to build a MDOS native program with GenProg. Especially if your code is self-contained (no assumptions about E/A or console ROM). 

 

The source should just use RORG. Assume you have 59K. Your address space is >0400 to >F000. You can put workspace in F000-F07E. F1xx-FFF9 is available.

 

You write a makefile and invoke it with MAKE.

In the makefile, you call ASM to produce object file(s). Then you call LINK to produce an executable.

GENLINK has its own control file, listing the input, output, and special directives. It can do quite a lot, besides making one big executable. (for instance, overlays.)

 

The specific things you'll have to replace with API calls are:

1. Keyboard scan
2. DSR access.
3. VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc.
4. Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API.
5. Allocating and mapping memory pages to fill the space above your program

 

If your Camel99 build system outputs object or binary on its own, you could make that work, too.

 

 

I understand most of that.  (What does RORG do?  Relative Origin?)  

 

I use my own cross-compiler so I can make it do whatever I need to but it does assume things load at a fixed address. 

LOL. Nope. No MAKE file here. Forth does all the building.  Bootstraps-R-US  

 

1. Keyboard scan   OK
2. DSR access.      Always tricky
3. VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc.  - So re-write my equates file
4. Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API. - don't do this 
5. Allocating and mapping memory pages to fill the space above your program -  Huh?  I thought I had >0400 .. >F000

 

And... the likelihood of me getting it right without hardware in my location to test it would be very slim. I am just not that good.

 

[+mizapf]

RORG = Relocatable origin; defines the following data and instructions as relocatable, i.e. the loader determines the actual location where they are stored in memory.

[GDMike]

Ears are perking up..hmmm

[+TheBF]

1 hour ago, mizapf said:

RORG = Relocatable origin; defines the following data and instructions as relocatable, i.e. the loader determines the actual location where they are stored in memory.

How does that work? I have never built anything like that. 

The Assembler image has to flag that somehow I guess.

Does the loader correct any addresses in the image or is everything relative to some reference value in the image?

Although my Forth compiler's code is relocatable using PC relative branches, the location of the two stacks have to be initialized to something and there are system variables that point to various addresses in the system for parsing text and managing the linked list of labels.

 

I would need to do some real study to make a RORG image I suspect.

 

[+FarmerPotato]

1 hour ago, TheBF said:

I understand most of that.  (What does RORG do?  Relative Origin?)  

 

 

5 minutes ago, TheBF said:

How does that work? I have never built anything like that. 

The Assembler image has to flag that somehow I guess.

Does the loader correct any addresses in the image or is everything relative to some reference value in the image?

Although my Forth compiler's code is relocatable using PC relative branches, the location of the two stacks have to be initialized to something and there are system variables that point to various addresses in the system for parsing text and managing the linked list of labels.

 

I would need to do some real study to make a RORG image I suspect.

 

RORG is the default setting in the TI assembler.

 

The assembler produces tagged object code files, with directives for relocatable address (starting at 0), absolute address, etc. These are "EA3", DIS/FIX80 format files.

 

The linking loader "corrects" or rebases relocatable symbolic addreses.

 

If you are producing a binary file, in a PROGRAM type, this is also known as EA5, it is not relocatable. The 6-byte header at the start tells the EA5 loader where to put it, how long it is, and if there are more files.

 

I'm sure you guessed that tagged object format is much bigger than PROGRAM binaries. It uses 5 hex digits to represent 2 bytes. A tag and 2 bytes. It also has checksum tags and symbol REF and DEF tags.  A 'compressed' variant uses binary instead of ascii, so a tag is followed by 2 bytes 0-255.

 

The linking loader knows the first free address in memory, and puts any relocatable segments starting there. It adds the starting address to local symbolic addresses in the object file, which are assembled as offsets from the program's start.

 

On the 4A, loading begins at the high memory at >A000. If that fills up, it goes to low memory at >2000-ish.

 

If your object file is relocatable, and the loader begins by putting it at >A000, the result is just as if you specified AORG >A000. Except, the first free address isn't updated.

 

GENLINK is a lot more versatile. You tell it which address ranges can hold relocatable code. But it outputs a memory image (or set of images) that are binary dumps of that memory. It takes place virtually, so you can link into any address range, or produce more than one output that will be overlaid.

 

The 4A linking loader only loads, it doesn't save PROGRAM images. To save images, you need to use TI's SAVE utility, or my SuperSave which does all the work for you.

 

 

 

[+FarmerPotato]

Here is a sample GenProg build process:

 

Source file SRCS

 

 

 

 

Batch File DOIT

ASM SRCS,OBJ,RS232,RLC
LINK !LINK

 

Control File !LINK

ADD OBJ
LIBREF LIB_MD
STATUS
SAVEALL PGM
EXIT

Command line:

 

A:>DOIT

... GENASM loads SRCS, outputs OBJ ...

... GENLINK loads OBJ, outputs PGM ...

A:>PGM

... PGM is loaded starting at address >0400, runs starting at >0400

 

Here is the file SRCS

Spoiler

	REF PRINT  subroutine from LIB_MD
	DEF START  unnecessary
	
	LWPI >F000
	B @START

* first argument to the system call XOP
KBOARD DATA 5
VIDEO  DATA 6
MEMORY DATA 7
DSR    DATA 8
UTILTY DATA 9
MATH   DATA 10
  
	.. equates and stuff ....

START

* Get and Map Memory the full 8 pages of RAM

* fill up the 64K memory space
* allocate our virtual pages 1-7 if they are not already
	LI   R0,1    allocate memory
	LI   R1,7
	LI   R2,1
	SETO R3     use fast memory if available
	XOP  @MEMORY,0

	MOV  R0,R0
	JNE  ERROR
	
* map virtual pages 1-7 to logical pages 1-7
	LI   R1,7
IN0	LI   R0,3    map memory
	MOV  R1,R2
	XOP  @MEMORY,0
	MOV  R0,R0
	JNE  ERROR
	DEC  R1
	JNE  IN0

* now do stuff

	BLWP @PRINT       subroutine from LIB_MD
	TEXT 'Hello World!'
	BYTE 0

* maybe initialize a heap starting at SLAST
* maybe initialize a stack extending down from >EFFE


SLAST EQU $
	END
	

 

 

Edited November 12, 2020 by FarmerPotato
oh crap I pasted my whole .plan file all 8k lines

[+TheBF]

20 minutes ago, FarmerPotato said:

The linking loader knows the first free address in memory, and puts any relocatable segments starting there. It adds the starting address to local symbolic addresses in the object file, which are assembled as offsets from the program's start.

Yes this is the tricky part. I don't have a "local symbolic addresses" table. Code and data are interwoven in a normal Forth system.

I could expand the compiler to create something but that is a PITA. 

I know the guys at MPE compile the Forth image twice a two addresses and then they can diff them to find the locations that need changing and compute the offsets from the load address.

Makes my head spin a bit but I suppose I could do it. I would rather not.  

[+TheBF]

Here is my command line to build the system.

 

XFCC99 FLOAD CC9900\SRC.ITC\CAMEL99.HSF

 

 

 

[+9640News]

4 hours ago, TheBF said:

I understand most of that.  (What does RORG do?  Relative Origin?)  

 

I use my own cross-compiler so I can make it do whatever I need to but it does assume things load at a fixed address. 

LOL. Nope. No MAKE file here. Forth does all the building.  Bootstraps-R-US  

 

1. Keyboard scan   OK
2. DSR access.      Always tricky
3. VDP access you can leave as-is, provided you use Geneve specific equates for VDPWA etc.  - So re-write my equates file
4. Console XMLLNK (and GPLLNK) will have to be replaced. MDOS has its own floating point API. - don't do this 
5. Allocating and mapping memory pages to fill the space above your program -  Huh?  I thought I had >0400 .. >F000

 

And... the likelihood of me getting it right without hardware in my location to test it would be very slim. I am just not that good.

 

In regards to #5, when you load a program in MDOS mode on the Geneve, the program load begins at >0400 and only fills upwards the 8K pages that will hold the image.  After the 8K page, no memory has been paged in from the next 8K page boundary up to >E000.  The address range from >E000 to >FFFF has a default page that is there. 

 

So, it is possible for a very short program, you would have a page at >0000 to >1FFF, and then by default, another page at >E000 to >FFFF.  Between those address ranges, if you want more memory, you have to request it from MDOS through the use of a Memory XOP.  You can request a list of all available memory (~1.5 MB if you have fully expanded 2 MB syste where MDOS is occupying some of the 2 MB memory and most users not having the last 128 MB ram that was reserved for an on-chip MDOS (PFM) so you do not have to boot from another device.

 

The Memory XOP’s have a lot of functionality as you can request memory that can be shared between two multitasking applications for inter task communication, etc.  There is a lot of potential there, just not widely used.

’

 

Beery

[+FarmerPotato]

1 hour ago, TheBF said:

I would need to do some real study to make a RORG image I suspect.

 

So never mind output tagged object format (RORG or otherwise).

 

If you are going straight to a binary file, there are some bytes you put at the beginning for MDOS.  GenLINK would do that for you (and it knows a lot of kinds of headers it can generate, including none at all) You are familiar with the 6 byte header on the 4A that tells EA5 where to load the PROGRAM file. This is something like that.

 

I looked for documentation but I can't find any...

So I opened an example in a hex editor. I see

0046   00 and the letter F
14B6
0400               this looks like a load address
1001   JMP $+4
5ac7   SZCB @02E0(R11),R7    certainly not code . let's go with DATA >5AC7
02e0   LWPI >F000
f000
0200 ...

 

I think the byte 0 at the beginning means there are no more files after this one?

 

BYTE 0    no more files after this

BYTE 'F'   'F' is for fast pages , 'G' would be for slow pages

DATA >14B6  length of this file. Max is >4000, beyond that you have to continue in next file

DATA >0400  load address

 

Help?

 

 

 

[+FarmerPotato]

10 minutes ago, BeeryMiller said:

In regards to #5, when you load a program in MDOS mode on the Geneve, the program load begins at >0400 and only fills upwards the 8K pages that will hold the image.  After the 8K page, no memory has been paged in from the next 8K page boundary up to >E000.  The address range from >E000 to >FFFF has a default page that is there. 

 

So, it is possible for a very short program, you would have a page at >0000 to >1FFF, and then by default, another page at >E000 to >FFFF.  Between those address ranges, if you want more memory, you have to request it from MDOS through the use of a Memory XOP.  You can request a list of all available memory (~1.5 MB if you have fully expanded 2 MB syste where MDOS is occupying some of the 2 MB memory and most users not having the last 128 MB ram that was reserved for an on-chip MDOS (PFM) so you do not have to boot from another device.

 

The Memory XOP’s have a lot of functionality as you can request memory that can be shared between two multitasking applications for inter task communication, etc.  There is a lot of potential there, just not widely used.

’

 

Beery

Beery, can you check my code in the file SRCS above? I put it together from bits I found on my floppy disks. 

 

According to GenPROG, it's harmless to allocate pages where you already have pages (it just fills holes). I'm not sure I ever used that .. I actually used BSS statements, a holdover from GPL programming.

 

So to fill up the whole 64K with RAM, I think I make sure that pages are allocated up to >07, then map 1-7.

 

Also I don't actually have the LIB_MD library, I just thought I would copy that example in.

 

[+TheBF]

41 minutes ago, FarmerPotato said:

So never mind output tagged object format (RORG or otherwise).

 

If you are going straight to a binary file, there are some bytes you put at the beginning for MDOS.  GenLINK would do that for you (and it knows a lot of kinds of headers it can generate, including none at all) You are familiar with the 6 byte header on the 4A that tells EA5 where to load the PROGRAM file. This is something like that.

 

I looked for documentation but I can't find any...

So I opened an example in a hex editor. I see

0046   00 and the letter F
14B6
0400               this looks like a load address
1001   JMP $+4
5ac7   SZCB @02E0(R11),R7    certainly not code . let's go with DATA >5AC7
02e0   LWPI >F000
f000
0200 ...

 

I think the byte 0 at the beginning means there are no more files after this one?

 

BYTE 0    no more files after this

BYTE 'F'   'F' is for fast pages , 'G' would be for slow pages

DATA >14B6  length of this file. Max is >4000, beyond that you have to continue in next file

DATA >0400  load address

 

Help?

 

 

 

Ok. That's something I can work with.

[+TheBF]

45 minutes ago, BeeryMiller said:

In regards to #5, when you load a program in MDOS mode on the Geneve, the program load begins at >0400 and only fills upwards the 8K pages that will hold the image.  After the 8K page, no memory has been paged in from the next 8K page boundary up to >E000.  The address range from >E000 to >FFFF has a default page that is there. 

 

So, it is possible for a very short program, you would have a page at >0000 to >1FFF, and then by default, another page at >E000 to >FFFF.  Between those address ranges, if you want more memory, you have to request it from MDOS through the use of a Memory XOP.  You can request a list of all available memory (~1.5 MB if you have fully expanded 2 MB syste where MDOS is occupying some of the 2 MB memory and most users not having the last 128 MB ram that was reserved for an on-chip MDOS (PFM) so you do not have to boot from another device.

 

The Memory XOP’s have a lot of functionality as you can request memory that can be shared between two multitasking applications for inter task communication, etc.  There is a lot of potential there, just not widely used.

’

 

Beery

So from this I could load my 8k micro kernel at >400 and then 

 

  TAKE OVER THE WORLD!  ?

 

Thanks Beery

[+9640News]

1 hour ago, FarmerPotato said:

Here is a sample GenProg build process:

 

Source file SRCS

 

 

 

 

Batch File DOIT

ASM SRCS,OBJ,RS232,RLC
LINK !LINK

 

Control File !LINK

ADD OBJ
LIBREF LIB_MD
STATUS
SAVEALL PGM
EXIT

Command line:

 

A:>DOIT

... GENASM loads SRCS, outputs OBJ ...

... GENLINK loads OBJ, outputs PGM ...

A:>PGM

... PGM is loaded starting at address >0400, runs starting at >0400

 

Here is the file SRCS

  Hide contents

	REF PRINT  subroutine from LIB_MD
	DEF START  unnecessary
	
	LWPI >F000
	B @START

* first argument to the system call XOP
KBOARD DATA 5
VIDEO  DATA 6
MEMORY DATA 7
DSR    DATA 8
UTILTY DATA 9
MATH   DATA 10
  
	.. equates and stuff ....

START

* Get and Map Memory the full 8 pages of RAM

* fill up the 64K memory space
* allocate our virtual pages 1-7 if they are not already
	LI   R0,1    allocate memory
	LI   R1,7
	LI   R2,1
	SETO R3     use fast memory if available
	XOP  @MEMORY,0

	MOV  R0,R0
	JNE  ERROR
	
* map virtual pages 1-7 to logical pages 1-7
	LI   R1,7
IN0	LI   R0,3    map memory
	MOV  R1,R2
	XOP  @MEMORY,0
	MOV  R0,R0
	JNE  ERROR
	DEC  R1
	JNE  IN0

* now do stuff

	BLWP @PRINT       subroutine from LIB_MD
	TEXT 'Hello World!'
	BYTE 0

* maybe initialize a heap starting at SLAST
* maybe initialize a stack extending down from >EFFE


SLAST EQU $
	END
	

 

 

i believe that should work once you add a label for ERROR. Myself, I get the map with the following code:

 

       LI   R0,4

       LI   R1,PGETBL

       LI   R2,8

       XOP @MEMORY,0

 

       MOVB @PGETBL+1,@>F111

       MOV   @PGETBL+2,@>F112

       MOV   @PGETBL+4,@>F114

       MOV   @PGETBL+6,@>F116

 

I get the map for the pages I requested and manage mapping pages myself without calling an XOP.  I've tried some of the memory XOP functions in the past, but you really have to be careful you call things correctly or things may not map where you think they should.

 

Beery

 

Beery

[+9640News]

16 minutes ago, TheBF said:

So from this I could load my 8k micro kernel at >400 and then 

 

  TAKE OVER THE WORLD!  ?

 

Thanks Beery

And I am sitting here watching Season 1, Episode 3 of NEXT where an AI is learning and expanding it's reach...............