Porting TI-99/4a software to Geneve 9640

[+retroclouds]

What are the limits and things to consider when porting TI-99/4a software to the Geneve?

In particular I'm considering if it would be feasible to port Stevie to the Geneve, letting it run in GPL mode.

 

Specs:

• 64K bank-switched ROM cartridge image, no GROM usage
• 1MB SAMS
• 8MB HRD4000b
• F18a

 

I'm aware there's no SAMS and no f18a on the Geneve.

So porting to the 9938 is the goal. 

Could perhaps use the HRD4000B as replacement for SAMS, if not using the HRD4000B as RAMDISK but as extended memory replacement.

[+FarmerPotato]

If you're not using console ROM or anything like that, GPL mode is just training wheels. At 6000 you can only have two banks. but you can change pages of RAM at other addresses. (Pretend 2000 is your cart space: I developed a 32K cart for 4A that way, switching 4 pages of RAM.) 

 

I've never been familiar with the HRD, but I think with ROMPAGE, GPL would show the actual card area at 4000.

 

 

In native mode, you can map memory however you like in the 8 banks of 8K. (Except that banks 0 and 7 have holes.)

 

I've not done it, but I guess you can map the PBOX DSR page too (HRD?) as it is just a physical page number. 

 

You're limited to the 544K or memory installed , minus GeneveOS.  There's also 128K total VDP RAM. 
 

you'd have to replace KSCAN etc with a simple XOP, and use the Geneve VDPWA etc (F102)

 

PAB format has a few different bytes. But in place of DSRLNK it's just an XOP. 

 

Hope that gets you started. 

[+9640News]

Ok. @FarmerPotato was mistaken about a thing or two. If you are going to run in GPL mode, then KSCAN is via a BL @>000E and not an XOP call.  Many TI assembly programs already do this. Only you do not want to do the hardware scan for keys which was more typical I think in some terminal emulators for speed. 
 

You can bank ram through one of the 8 mapper registers in GPL mode. I think you have available something like 128K of 8 K ram banks as MyWord on the Geneve uses this as well. I would have to double check what pages TIMODE reserves for GPL mode to know for sure. Another option, you do have 128 K of VDP ram available as well. I am not sure if you can use the cartridge space to bank all the 8K banks into, but you can use it for at least an 8K program memory space so you can shift the swapable bank to another location. I would not use the E000 to FFFF range sine the last 4 bytes are tied to a load interrupt vector. 

 

in GPL mode, all video ports remain the same. 
 

 

[+InsaneMultitasker]

F18A vs. 9938 - 80 column text mode is just like 40 column mode on the TI, except there is a blink attribute that lets you highlight any screen position with its own fore/background colors.  As mentioned above, the Geneve has base of 128K VRAM.  You can use graphics mode 6 to display 16-color text (think IBM ANSI) but each character is drawn so speed is typically a concern here, at least for "editing" files.

 

SAMS - difference here is the 4K versus 8K memory windows.  If you are mapping memory, it needs to be in 8K chunks. There is the reserved MyWord 64K that comes with TIMODE. You can also request more memory from the system with some effort.

 

Cart Port - there is 8x8K (64K) GROM memory that can be accessed as GROM or via mapped page as RAM.  You're limited to 16K ROM/RAM via the cart port.

 

Consider what your desired goal is and that will help determine the approach and what RAM to use.  GPL mode is pretty much like a standard /4A except you cannot scan the keyboard directly via CRU bits.  Also, native 9640 mode isn't a huge leap but certainly some learning curve beyond GPL. Again, depends how far you want to go with this. 

 

Edit: minor corrections

 

[+mizapf]

For low-level keyboard control, see https://www.ninerpedia.org/wiki/Geneve_keyboard_control but I guess the standard XOP access should be good enough.

 

By the way, I'd love to see it running in native mode (MDOS) since I understand GPL mode just as a compatibility mode to let legacy software run. This is, of course, my personal view.

[+retroclouds]

The only things I’m “borrowing” from the TI-99/4a OS is KSCAN and level 3 FIO. 

Other than that it’s just pure assembly language code. 

Actually the design I had in mind should allow portability to other 9900 series based systems with a TMS9938/TMS9958/F18a VDP quite easily.

But yes, I think getting file I/O in place is probably the thing that would require most work.

 

Having said that would love to get it running on the Geneve. Will see how that goes and when to start working on it.

 

 

[+retroclouds]

I looked at the physical memory map of the Geneve, both TI-mode and native mode, but still somewhat confused.

 

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

 

So in native mode, how large can a continuous memory region be, also in regards to MDOS alllocation ?

 

If I would tackle this project I would use MAME for development.

I do have a Geneve 9640, but it’s unexpanded.

 

On the TI-99/4a it’s a 64K bankswitched cart and memory wise I’m using regions >2000, >3000, >A000, >B000, >C000, >D000, >E000, >F000

 

Low memory expansion does not bank-switch. 

But do am mapping high-memory expansion.

 

Details below (needs to be reworked, but most of it still stands)

https://github.com/FilipVanVooren/stevie/blob/master/docs/devs/sams.md

Edited April 11, 2023 by retroclouds
Forgot >F000

[+mizapf]

For the question about the contiguous memory, this should be interesting for you as well: https://www.ninerpedia.org/wiki/Geneve_logical_memory_map

 

[+9640News]

5 hours ago, retroclouds said:

I looked at the physical memory map of the Geneve, both TI-mode and native mode, but still somewhat confused.

 

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

 

So in native mode, how large can a continuous memory region be, also in regards to MDOS alllocation ?

 

If I would tackle this project I would use MAME for development.

I do have a Geneve 9640, but it’s unexpanded.

 

On the TI-99/4a it’s a 64K bankswitched cart and memory wise I’m using regions >2000, >3000, >A000, >B000, >C000, >D000, >E000 

Low memory expansion does not bank-switch. 

But do am mapping high-memory expansion.

 

Details below (needs to be reworked, but most of it still stands)

https://github.com/FilipVanVooren/stevie/blob/master/docs/devs/sams.md

On the Geneve, there are 8 by 8K banks of memory from >0000 to >FFFF "as is".  Two of those 8K banks really should never be banked at >0000 to >1FFF and >E000 to >FFFF.  In the >0000 to >1FFF range, this page contains from >0000 to >0400 code for the handling of XOP's, etc. for the operating system.  In the upper bank of memory at >E000 to >FFFF, there is an overlap with the high speed ram of the 9995 chip.  So, really speaking, you should be able to bank in any memory from >2000 to >DFFF in 8K chunks.

 

When your MDOS aprogram loads, MDOS will only allocate 8K banks to accommodate the space for the program.  So, let's say your program is only 1K in size (>0400 bytes in length).  It would begin loading at >0400 and fill up to >0800.  You still have the rest of the 8K bank available up to >1FFF.  By default, MDOS provides a page at >E000 to >FFFF.  No memory will be assigned between >2000 and >DFFF.

 

To add memory, you then need to request via the use of the memory XOP, how many 8K banks of memory you need/want.  There is one call to determine how many pages of free memory there are, and another to get that list of free memory pages.  Then, you have two options.  You can request from MDOS a list of those 8K page numbers that are free and drop them into a buffer in your program, or you can use a MDOS Memory XOP call to place a page at any memory location.  So, if you had an expanded memory system, you might request 128 x 8K pages.  If you want to handle memory mapping on your own, you would simply use a MOVB  @PAGLST+120,@MAPPER+"x" where "x" is the offset of the mapper pages from >F110 to >F117 keeping in mind the page at >F110 is for >0000 to >1FFF and >F117 is for >E000 to >FFFF that should not be used for mapping additional code within.  The other option is to have the MDOS Memory XOP call to page a virtual memory bank into the present memory range.

 

One of the nice features of the DSR XOP calls is that you can tell MDOS in the PAB to set a location to load file, data, etc. into memory that is not presently mapped within your current memory range of >000000 to >00FFFF.  You can essentially tell it to load at >010000 which would put the file loading at the memory in the 9th 8K page of memory.  Or, you can tell it to load into VDP anywhere within the 128K memory range.

 

Four lines of code will return to you a key, four lines of code will set any video mode, three lines of code (plus a PAB definition) will execute a DSR call, and more. It is actually quite a bit easier to program in MDOS assembly mode than on a TI-99/4A due to all the XOP "libraries" of functionality.  And if you don't like the video XOP calls for doing your video work, you can still write to the video ports on the 9938 chip, but just at a different address.

 

There are a reasonable number of examples of source code for all these things, plus the GenREF set of MDOS XOP documentation has all the details.

 

 

[+9640News]

One other question I see you asked.  I have personally had 8 by 8K program segments loaded to use the fully 64K memory space.  I have never tested having additional 8K pages to see if they would load into virtual memory.

 

What you can do though is have a primary section of program, then have code segments that could be saved as a much larger block say for example a 64K block.  Your primary section of program could then load this 64K block into either RAM or VRAM. If RAM, then you would just map when needed an 8K block into your working 64K block (physical) memory space.  Or, if in VRAM, rather than map the code in, you would copy VRAM to CPU RAM in the physical address space of >0000 to >FFFF somewhere.  It all depends upon where you want to store code and whether you want to use CPU RAM or VRAM as your text buffer space.  

 

This may all seem complex, however it really isn't.  It is probably easier to do a Zoom call to show you some examples and to answer specific questions and you would be well on your way in a day or two since you have a pretty good understanding of assembly already.

[+retroclouds]

This is starting to become a great thread. Thank you all for the information supplied.

Where would I find some good source code examples for doing file I/O on the Geneve?

[+9640News]

I will try and pull you some code examples tonight.  

[+dhe]

@retroclouds - You are in an interesting spot.

 

When the Geneve came out, most people where only interested in coding for MDOS, there where very few programs that where made to run on the TI with Geneve enhancements.

 

One article I remember, but I could not locate was an introduction to Geneve Program - I think it was by Peter Hoddie - where he talked about some of the same things in an abbreviated version that @9640News spoke of.

[+9640News]

10 hours ago, retroclouds said:

This is starting to become a great thread. Thank you all for the information supplied.

Where would I find some good source code examples for doing file I/O on the Geneve?

OK, here is a rather large zip file with lots of source code.  I have several projects with source in this code and will give a brief description what you may find in the source.

 

GRAPH - GEME source with a lot of direct VDP writes as well as some video routines.  It requires a mouse to use, and was a first attempt at least drawing up spreadsheet type screen.  It has some useful examples, however I believe the other source files may be more beneficial.

 

KEYTEST - Program I wrote to verify what some of the keypresses would return as a hex byte depending upon what keymode was selected from the XOP.

 

MEM - Memory test program.  Moves code into on-chip 9995 High Speed ram so that any memory page tested does not ovewrite existing code.  Has some useful VDP direct write routines in the code.

 

SERVER - Program I wrote for the next MDOS release that exercises some of the memory routines for the next MDOS release.  Gives various examples on shared memory for intertask communication as well as an example of loading a program from within a program.  It is unlikely you will be needing intertask communication, but calling memory routines here is a good start.

 

WIPE-PGM - Another program for showing examples of accessing all available free Geneve memory.

 

BIBLE - This is a large folder, with some very large data files in Program Image file format.  These program image files are accessed on a sector basis with DSR pabs for file sector access.  One source file in this folder, BIBLEMYART, is an example on a PAB configuration to read a MyArt DIS/FIX 128 file in and then displaying it.  I haven't looked at the source in too close of detail lately, but gives you a lot of examples of what can be done such as drop down menus, etc.  Originally, I had all the verses of the Bible in an Excel spreadsheet I got from the Internet.  I had to write a program to convert an export of the spreadsheet (CSV????) into a format that I could then convert and save as a Program image file.  I discovered somewhere in the MDOS DSR document a reference that lead me to believe record sizes could be greater than 255 bytes, however it looks like this may have never been enabled.  So, rather than having a 1000 byte record, I wrote various index routines and stored everything in Program image files.

 

I would definitely recommend you get all the manuals at GenREF Documents – 9640 News as this is the best documentation on all MDOS XOP usage.

 

Hope this helps.  If you have questions, please feel free to inquire as myself and others will be more than happy to point you towards the right answer.

 

EXAMPLES.zip

[+retroclouds]

That’s quite the collection, thanks! 😃

 

So here’s my plan. From what I understand so far I would go for a native conversion and not run in GPL mode.

Before I start doing that I’d like to get some hands-on experience on the Geneve and understand the architecture better by reading up on the provided documents. Will also do a bit of code refactoring in the next 1 or 2 minor versions of Stevie.

Basically abstracting away some more of the VDP functions in the first place.

 

Also need to look at spectra2, which is the low-level library I use for all things related to task handling, input/output, etc.

Still unsure if I would keep as is, or if I could map many of these spectra2 calls to MDOS calls. 

Thinking of it like having a thin spectra2 compatibility layer around these MDOS calls.

With that in place I could then start doing a Geneve port.

 

To keep things aligned, I’d like to have a single source code base, both for the TI-99/4a and Geneve version, hence the required refactoring.

The idea of having 2 code bases that start to diverge is not something I’m particular fond of, we’ll see how that goes.

 

Anway, I’ll gladly come back to your offer on the zoom call, when the time comes to discuss the details.

[+9640News]

If you start assembling your project with GenASM, you will have some additional flexibility to have a single code base.  GenASM has some conditional assembly features.

 

One place for video they can be used is if you use EQU's for your video ports.  So, the assembly process would be something along the lines of "IF MDOS" then use these EQU's, else it presumes TI-99/4A and use these EQU's for the video ports.

 

Something a bit similar can be done for your code branches to get keyboard input.

 

DSR activity will be a bit more tricky.  With the TI-99/4A, the PAB's are copied to VDP.  For MDOS, the PAB's remain in CPU RAM.  Now, where data is returned for MDOS can be either CPU RAM or Video RAM.  So, you can still read/write the same data (not PABS) with the same routines by setting the MDOS PAB to video writes so your VRAM layout can still remain the same.  You just would need to make sure all changes to the PAB(s) are handled by a common set of routines.  I don't recall if your project would have multiple files open simultaneously, or just a single file.

 

When I converted Stuart's TIPI web browser program from a TI-99/4A program to MDOS program, I added code to have a full 64K CPU RAM for the program, modified the keyscan routine, and changed the DSR routines.  His layout of the DSR code was a very tight piece of code, however because he was writing bytes to VRAM to change OPEN/READ/WRITE?CLOSE made things more complex as he was handling multiple files but all with one tight piece of code.  I would almost suggest having code accessed from a BL/BLWP call that changes the PABS to OPEN/READ/WRITE/CLOSE in one very specific section instead of inline code scattered throughout the codebase.  This way, you can use the conditional assembly features to use IF MDOS or IF TI99.

 

I did something very similar for the AfterHours BBS source code, but that was strictly for the TI-99/4A.  There were conditional assembly features to specify text specific to Greg's "The KEEP BBS", Wolfgang's TBOX99 BBS's, and the default version of the BBS.  Wolfgang's had two versions of the source running on two setups.  One that had conditional assembly for German Text, and the other that had conditional assembly for English Text.  Everything was all in one codebase and was easy to maintain.

 

Beery