Geneve Questions!

[+InsaneMultitasker]

Care must be taken to know when you are referencing local pages versus virtual pages.  What you need to keep in mind is the local address space is 24 21 bit even if you are typically looking at it from a 16-bit perspective.  It is easy to get tripped up. For example, with the disk DSR XOPS, the 24-bit buffer address allows you to load data into a page that is not in your 64k visible window then map the page in and access the data.  Experimentation with the memory and dsr xops is a good starting place, and MAME debugger is helpful if you wish to figure out what is happening behind the scenes.   As for holes and other concepts, I still get tripped up ... (Edit: corrected error above)

[+TheBF]

Sounds wicked complicated. Not good for my old brain.

Does anyone run it like an intel segmented model? (Code here, data there  ,extra stuff somewhere else)

 

How does a 9900 type CPU deal with the extra 8 bits of addressing?

Is it in a hardware register somewhere?

[+InsaneMultitasker]

Complicated usually comes into play if you need a lot of overlaps and such.  Most of us don't get into the complicated addressing, I should have prefaced my comment by stating for most programs, it is pretty simple once your memory map is set up.  DSR operations in the Geneve OS are much simpler IMHO, as you can can use CPU RAM for any device, work with the PAB in CPU RAM, and point the OS to it.  No DSRLNK or other complications. 

[+FarmerPotato]

1 hour ago, TheBF said:

Sounds wicked complicated. Not good for my old brain.

Does anyone run it like an intel segmented model? (Code here, data there  ,extra stuff somewhere else)

 

How does a 9900 type CPU deal with the extra 8 bits of addressing?

Is it in a hardware register somewhere?

 

You can use the small memory model of 64K until you need more. When you need more, you could implement overlays. It's a lot like SAMS.

 

There's no 8086-style segment registers in the hardware.

 

The TMS9900/9995 doesn't make separate code and data segments possible. The TMS99105 does--I'm reluctant to use it.

 

Geneve has an external memory mapper with 8 8-bit page registers.

 

A memory mapper is an external chip (see 74LS612 from TI. It's in SAMS). In the Geneve, it's a set of 8 registers, each holding 8 bit page number. Each mapper register governs 8K of the 64K logical address space. (TI prefers 16x4K pages, Geneve implements 8x8K pages.) 

 

The external memory mapper in the Geneve works by taking the top 3 address bits (of 16). It gets the 8 bit page number from one of the 8 registers, which replaces those 3 bits on the wider bus.  So the 16-bit logical address has become a 16-3+8=21 bit address for 2MB of address reach. Or, 256*8K.

 

The Geneve sends those 21 address lines across the Pbox backplane (after using them onboard, to address its own chips).

 

That's the physical address side.

 

 

 

 

In the Geneve, there are 256 physical pages. In the MDOS task model, each task has a table of 256 virtual pages. Physical page numbers are allocated into there starting at 0. The 8 mapper registers are populated with the physical page numbers. Either by direct write to the register, or an XOP call.

 

It's up to the task to decide, when to move a physical page number from its virtual map, into a mapper register.

 

But certain XOP calls (DSR) accept 24-bit addresses -- these are translated to physical page numbers by looking at the task's virtual page table.

That's just software.

 

When DSR needs to read or write data for the calling task, it looks up the task's physical page page and maps it in. 

 

This would be better with some illustrations

 

Example

A task initially had 1 page or 8K of memory. The OS loaded it in physical page >99. So its virtual map is just [99,...] 

 

The task asks for 15 more pages, to reserve 128K of memory in all. 

 

Suppose it is handed physical pages >31 to >3F. (they need not be consecutive--fragmentation.) The OS puts them in the task's virtual table,

which is now [99,31,32,33...3F]

 

It's up to the task to move the physical page numbers into mapper registers. It could copy the first 8 into the eight mapper registers (page 0 must never change) That's a flat 64K memory model.

 

Or say you want to split it into 32K of always-present, and 32K of paged pages.

 

The task would move 4 physical page numbers from the first 4 virtual pages into the first 4 mapper registers.

Then it could fool around with the next four. It could use the top four banks to have up to 32K of its other 96K mapped in at one time.

 

Now it can ask the DSR to read in a whole file. It can ask the DSR to grab 96K of the file and put it at virtual address >8000. Or it could ask the DSR to go get 32K of some other file and put it at virtual address >18000. The task doesn't need to map this in. The DSR figures out how to get it done, and cleans up after itself.

 

Once the task resumes, it fiddles with its mapper registers to bring some of that virtual buffer space into some of that upper 32K.

 

*

 

It's not really a 24-bit address, just because it fills 3 bytes. There are really only 21 bits of address possible.

 

 

[+retroclouds]

That is most interesting. I wasn’t aware of MDOS being able to run tasks and its memory handling.

Is there a MDOS development manual where this kind of stuff is explained?

 

Suppose I want to write a Geneve native assembler program, then that would be very valuable information. Thanks.

[+FarmerPotato]

46 minutes ago, retroclouds said:

That is most interesting. I wasn’t aware of MDOS being able to run tasks and its memory handling.

Is there a MDOS development manual where this kind of stuff is explained?

 

Suppose I want to write a Geneve native assembler program, then that would be very valuable information. Thanks.

Whtech. I put some links here yesterday. 

 

[+FarmerPotato]

I think first you read the Utility system calls doc in GenREF. 
Then go to the MDOS src to learn how the task model works. 
 

Tasks get switched out after a certain number of VDP ticks. 
 

MDOS doesn’t use the 9901 decrementer but I guess counting VDP ticks is fine enough. 

[+TheBF]

8 hours ago, retroclouds said:

That is most interesting. I wasn’t aware of MDOS being able to run tasks and its memory handling.

Is there a MDOS development manual where this kind of stuff is explained?

 

Suppose I want to write a Geneve native assembler program, then that would be very valuable information. Thanks.

I found the 9900 multi-tasks very well because of the ability to switch workspaces.  The context switching time on the Camel99 multi-tasker is on the order of 20..30 uS.

I have not made a "ready-for-prime-time" version yet but I experimented with creating processes in SAMS memory on the TI-99 where I swap out the working memory for each process and it still is a reasonable context switching time for a small number of processes.  

 

From what I read Geneve was designed with much more of that baked into the design. Mastering it seems to be the challenge.

[+mizapf]

Also, you can look into https://ftp.whtech.com/Geneve.new/ as more files are getting stored there. I already put the GenASM docs there.

 

[+9640News]

10 minutes ago, TheBF said:

I found the 9900 multi-tasks very well because of the ability to switch workspaces.  The context switching time on the Camel99 multi-tasker is on the order of 20..30 uS.

I have not made a "ready-for-prime-time" version yet but I experimented with creating processes in SAMS memory on the TI-99 where I swap out the working memory for each process and it still is a reasonable context switching time for a small number of processes.  

 

From what I read Geneve was designed with much more of that baked into the design. Mastering it seems to be the challenge.

When I wrote Windows 9640, I had done quite a bit of disassembly of various pieces of MDOS along with a number of questions to Paul to understand various pieces of memory.  While using Bruce Hellstrom's memory CPU/VDP viewer and it also has a built-in disassembler (assembly source code is also out there), you could watch the timer decrement from a >06 to >00, and if there were other tasks in an active state, it would switch to the next task.  You could also control the amount of time allotted by a task by changing the value of that one byte to give it a shorter or longer lifespan.

 

I passed some code on to Bruce, and from it, Bruce wrote a mouse driver for both the Geneve Mouse, as well as a separate driver for an RS232 based mouse.  It created a "control register" area in memory that would return mouse button movement/position, mouse button status, etc. to ease mouse useage.  I'm not sure if Mike Maksimik implemented the mouse driver in CFORM, but I think Al Beard did with his GenBench Shell package.

 

Now, many years later, Windows 9640 itself wasn't all that great of a program, but it did have some useful functions with its XOP that were part of the program.  It wasn't until after I released Windows 9640, did Lou Phillips show me what @webdeck had been doing with GEME which was truly some great unfinished work.  I still look at his code from time to time, and have tried to do some things such as a new program with his code base, but things got sidetracked.  

 

I did write some other code years later that demonstrated the capability to do a TSR type program that installed within MDOS that could be activated by a keypress.  I don't recall who made the inquiry anymore, but I spent one afternoon putting the pieces together and writing some example code demonstrating the capability.  That example I think is on the MAME HD image (directory TSR??) that some have, as well as in the Files section of the Yahoo Geneve group dump.

 

Beery

[+9640News]

4 minutes ago, mizapf said:

Also, you can look into https://ftp.whtech.com/Geneve.new/ as more files are getting stored there. I already put the GenASM docs there.

 

If someone wants to ever add more information to the GenASM docs, I have the original Word Files that were used to generate those docs.  Most of it is Paul's original text converted from a much older (unix???) document program, however the docs on the Video I think I put together on everything I could find/learn.  There is an outside chance some of the XOP video opcodes could need an update as there were some things Jim Uzzell and Clint Pulley may have added or requested over the years.

 

Beery

[+TheBF]

Hmmm... TSRs and hotkeys.  I haven't done that since MS DOS.

 

Should be pretty simple in my world. Kind of "sixes" though when literally everything is a text command away.

One more project on the stack...

[+FarmerPotato]

3 hours ago, BeeryMiller said:

If someone wants to ever add more information to the GenASM docs, I have the original Word Files that were used to generate those docs.  Most of it is Paul's original text converted from a much older (unix???) document program, however the docs on the Video I think I put together on everything I could find/learn.  There is an outside chance some of the XOP video opcodes could need an update as there were some things Jim Uzzell and Clint Pulley may have added or requested over the years.

 

Beery

 

Beery, I found the originals on whtech the other day. 

 

whtech has GenREF in the .doc format as well as PDF.  They are in http://ftp.whtech.com/Geneve/mdos/MDOS Development documents/

inside GenREF.zip. In there is a README.doc that Beery wrote in 2004.  It mentions the nroff format.

 

The early-access MDOS docs GENERAL, MEMORY, MATH etc (but not VIDEO) were in nroff format.   Hey, just the other day those old files were in http://ftp.whtech.com/Geneve/GenProg/  but they are not now.

 

The original scans like 'GenLINK by Paul Charlton 1989.pdf' look to me like they were created using nroff.

 

Anyhow, Beery's doc and pdf versions supercede those.

 

If you have those nroff files, you can easily format them to your PC screen:

 

1. Download Cygwin64 tools. In the installer, make sure you choose to install the nroff package!

2. Open Cygwin command shell. 

3. Navigate to your directory with 'cd /cygdrive/c/ti99/whtech/Geneve/GenProg' or whatever. (this is your C drive. use forward slashes)

4. nroff MEMORY | more

 

 

I resisted the urge to post digressions on nroff, LaTex, Donald Knuth...

 

 

 

[+FarmerPotato]

@BeeryMiller All, it's past time for me to say a big Thank You to Beery for all the support he's put behind the Geneve, going back to the beginning.

Without Beery's efforts, we would not have most software updates, or the source to MDOS.   Also he published 9640 News for a long time.

 

 

 

[+9640News]

I received more than enough thanks back in the day.  The big guy to thank now is @InsaneMultitasker for all his work and efforts he has put into the updates along with people like Mike Maksimik, Clint Pulley, Alan Beard, Jim Uzzell, James Schroeder, and others throughout the years.  Without everyone's support, we may have had the source code, but not the talent to further its development.  As it is now, just about all the work has been done by Tim.  He inquired about my assistance with the TIPI interface to the master DSR a few months back, but I was so far behind the times and really far behind on the DSR coding, I would have been a hindrance to where he has the current work.

 

Beery

[+9640News]

1 hour ago, FarmerPotato said:

 

Beery, I found the originals on whtech the other day. 

 

whtech has GenREF in the .doc format as well as PDF.  They are in http://ftp.whtech.com/Geneve/mdos/MDOS Development documents/

inside GenREF.zip. In there is a README.doc that Beery wrote in 2004.  It mentions the nroff format.

 

The early-access MDOS docs GENERAL, MEMORY, MATH etc (but not VIDEO) were in nroff format.   Hey, just the other day those old files were in http://ftp.whtech.com/Geneve/GenProg/  but they are not now.

 

The original scans like 'GenLINK by Paul Charlton 1989.pdf' look to me like they were created using nroff.

 

Anyhow, Beery's doc and pdf versions supercede those.

 

If you have those nroff files, you can easily format them to your PC screen:

 

1. Download Cygwin64 tools. In the installer, make sure you choose to install the nroff package!

2. Open Cygwin command shell. 

3. Navigate to your directory with 'cd /cygdrive/c/ti99/whtech/Geneve/GenProg' or whatever. (this is your C drive. use forward slashes)

4. nroff MEMORY | more

 

 

I resisted the urge to post digressions on nroff, LaTex, Donald Knuth...

 

 

 

I've seen the GenProg file move around, disappear, reappear, disappear, etc. a number of times on Whtech.  It always makes me nervous when things are moving around as I wonder if at some point it will just disappear and I will be the only resource.

 

Now, just about everything I do I am trying to release things into a large enough domain that hopefully someone will have archived the program should someone ever desire to seek the program or code again.

 

Beery

 

 

 

[+mizapf]

10 minutes ago, BeeryMiller said:

I've seen the GenProg file move around, disappear, reappear, disappear, etc. a number of times on Whtech.  It always makes me nervous when things are moving around as I wonder if at some point it will just disappear and I will be the only resource.

For that reason, I set up the new directory Geneve.new and only copy things inside, not move. ?

 

[+dhe]

>It mentions the nroff format.

 

I didn't know that. Many years ago, I wrote a little help file for MDOS, people could do a help dir - an get examples.

 

I've used nroff a lot to create custom man pages, I probably could have pulled off a man page like system....

[+InsaneMultitasker]

 

@mizapf ,  earlier today I was trying to locate  @jedimatt42's instructions for booting a Geneve from a Horizon ramdisk.  I launched the ninerpedia main page and then clicked through to the Geneve page via the picture. I couldn't find the instructions there so I went back to click through the other links.  I eventually noticed (and used) the search feature to find the page:

 

https://www.ninerpedia.org/wiki/Booting_MDOS_from_Horizon_Ramdisk

 

My search also revealed a 2016 page for configuring ROS/CFG on the TI with some neat pictures (but that might need a few updates) :

 

https://www.ninerpedia.org/wiki/Setting_up_the_Horizon_Ramdisk

 

Had I not known about the Geneve instructions from an AtariAge post, I don't know that I would ever have found them on ninerpedia.  Is there a way to link the pages to a topic?   If not, it might be helpful to suggest the use of the Search feature and call out that more information is available than presented in the main page links.

 

I am sharing this experience for awareness and not as a criticism of the site.

 

[GDMike]

On 11/14/2020 at 12:31 AM, dhe said:

>It mentions the nroff format.

 

I didn't know that. Many years ago, I wrote a little help file for MDOS, people could do a help dir - an get examples.

 

I've used nroff a lot to create custom man pages, I probably could have pulled off a man page like system....

I got that help on disk with my geneve I bought.

[+mizapf]

@jedimatt42 obviously wrote these pages some months ago (View history); I was not aware of them. As a quick remedy, I put a link on https://www.ninerpedia.org/wiki/Geneve_9640

 

The whole Geneve section needs some cleanup and update, actually.

Edited November 18, 2020 by mizapf

[+InsaneMultitasker]

On 11/12/2020 at 3:47 PM, BeeryMiller said:

I received more than enough thanks back in the day.  The big guy to thank now is @InsaneMultitasker for all his work and efforts he has put into the updates along with people like Mike Maksimik, Clint Pulley, Alan Beard, Jim Uzzell, James Schroeder, and others throughout the years.  Without everyone's support, we may have had the source code, but not the talent to further its development.  As it is now, just about all the work has been done by Tim.  He inquired about my assistance with the TIPI interface to the master DSR a few months back, but I was so far behind the times and really far behind on the DSR coding, I would have been a hindrance to where he has the current work.

 

Beery

I feel the OS-work has always been a collaborative effort - starting with the time and effort you put into obtaining the OS source, distributing it to the developers, and providing the support backbone to make enhancements possible.  Most of the people involved in the development heyday have since left the community and some like Gazoo and Jim Uzzel are no longer with us.   The neat thing (to me) is the "resurgence" in activity, fostered by the AA community.  I only wish that for my part that I had more time for the hobby like I did 15-20 years ago. 

[+InsaneMultitasker]

I came across this old TI NET / Delphi transcript from 1988 with Paul, JPH, and others hiding on an old disk.  (I wish we had archives of the old conferences and messages.)  I'll look for other nuggets as I poke through my files. 

 

 Delphi Charlton 1988.txt

 

Anyway... the following exchange caught my attention.  @mizapf and  @jedimatt42 could this possibly be a contributing factor to the inability to use the TI disk controller in the Geneve 'rompage' environment?

 

..PaulC> you have to map in the DSR page, which is page #  > BA  (hex)
99SG> How then?
..PaulC> and from there it's a real chore......
..PaulC> since the corcomp and ti disk controllers have to be controlled
  completely from software
..PaulC> (the Hardware wait feature on the /4a is not functional on the Geneve,
  so the software has to be extra smart)
..PaulC> that's all I can say in less than a few hours
** ABEARD just joined "TI NET SPECIAL 99/4A & 9640 CONFERENCE" (13 members now)
  **
99SG> can it be done from gpl?
99SG>
..PaulC> followup?
..Mike> Same way, 99SG..
..jph> sure........just the same as it would be done under MDOS
..PaulC> with much pain and suffering!
..Mike> I can attest to the suffering part <cough>

 

 

[+mizapf]

This is a bit short as an explanation. There is no fatal hardware deficiency, otherwise GeneveOS would not be able to use the controllers by its master DSR. I once encountered an interesting issue with the BwG controller in the emulation. Maybe this was fixed later, as some people claimed that the BwG controller worked with the Geneve.

 

With the WD177x/WD179x controllers, you don't have the luxury of having a cache RAM as the HFDC does. Thus, you must pick up every single byte that has been read by the CPU. Usually this is solved via the READY line: Doing a MOVB @>5FFx,Rx arms the "READY trap" which locks the CPU inside this operation by pulling down the READY line. This is until the controller signals a DRQ (data request), indicating that a complete byte has been read. In that moment, READY is released, the MOVB instruction continues and gets the byte from the data register. This is repeated for every byte until the command has completed.

 

With the BwG there is an interesting issue: The READY trap is triggered by the odd address (e.g. 5FF9, not 5FF8) by the circuitry. This can be seen as the A15 address line must be 1 to enable the lock.

 

With the TI-99/4A, you should know by now by our discussions on this forum that a MOVB is in fact the same as a MOV, since the TMS9900 cannot access single bytes. Only inside the CPU is the byte operation actually peformed differently. So a MOVB @>5FF8,R0 first does an access to 5FF9, locks the CPU there, then waits for the release, and then gets the byte in the second read  (the even address 5FF8).

 

Now for the issue on the Geneve: The TMS9995 does real 8-bit accesses to external memory. When you do a MOVB @>5FF8,R0, the address 5FF9 is never seen on the bus, and the READY trap is not operational.

 

From the citation above, it seems as if the READY trap concept did not work in general on the Geneve, but this cannot be true, since this would mean that the TI controller cannot work at all. I don't think you can somehow emulate the READY trap by constant polling.

 

The answer to this question lies in the code in the boot EPROM. If I find some time, I can check it more closely.

[+OLD CS1]

3 hours ago, mizapf said:

some people claimed that the BwG controller worked with the Geneve.

FWIW, I just recently tried a Geneve with both a CorComp DDCC-1 and a BwG, and the BwG worked perfectly.