What is GPL w/ROMPAGE exactly?

[+jedimatt42]

The Geneve GPL ( version 6.50 ) has an option ( F5 ) labelled GPL w/ROMPAGE. It takes me to the title screen when I press it. What is it supposed to do?

 

And on a hopefully related note, how many cartridge port rom pages does GPL on the Geneve support? The memory map indicates just the 16k worth.

 

Thanks,

-M@

[+Ksarul]

It supports just two 8K banks of ROM, along with the 8 GROMs. It was definitely not set up to support things like the current generation of cartridges--or even the one original TI-manufactured cartridge that had four ROM banks (TI-Calc).

[+InsaneMultitasker]

The Geneve operating system contains its own DSR (device drivers) for the peripheral cards it recognizes. It does not scan the peripheral cards during a device call as it uses its own internal device table.

 

The ROMpage function bypasses the Geneve OS "device drivers" and allows programs to use the on-card DSRs within their respective EPROMs. This is most often used for certain hard drive specific programs, since the Geneve OS does not fully emulate the required DSR calls. For example, Archiver 4.0g must be loaded using the ROMPAGE option to properly access SCSI and HFDC drives.

 

If you select ROMPage with a floppy controller, you will probably not notice any difference. One noticeable exceptions to the rule is the Myarc FDC. The card is timing dependent and will often fail at speeds above 3 (when ROMpage is called), since the on-card EPROM timing loops expire too quickly.

 

Both GPL and EXEC provide ROMpage functionality from the menu and command line, respectively. Unless you have a specific need for ROMpage, it is best not to use it.

[+jedimatt42]

That is a very interesting feature. That must be the mechanism by which Fred Kaal's DSR for the IDE board works, as he simply says: "This also works on a Geneve (in TI-mode off course)"

 

Is there a site with a list of the hardware that the Geneve supports? and or is known to work?

 

The manuals I've seen cite the some level of function with the TI FDC, CORCOMP FDC, MYARC FDC, the same 3 brands of RS232 card, and the Myarc HFDC.

 

What other devices are known to work? (cause now you've got me curious )

[+Schmitzi]

Hi,

 

as I am already tagging all software-products for relation with the Geneve,

I am now tagginig the hardware too. (I follow all threads for that)

 

So, what about the BwG, the WDS, the SCSI-Controllers we have, do they run on Geneve ?

 

Thx

 

[+Schmitzi]

...there already was this list So I added all info I could find in the Gene-Manual. as a small start:

 

 

TI-99-4A-GENEVE-9640-v1.14-beta.pdf

[+mizapf]

I am not sure about the compatibility of the BwG and the Geneve. I heard that there are BwG cards that obviously work, but judging from the schematics I have I would guess that in general, BwG cards are not compatible with the Geneve.

 

There is some circuitry on the board which inserts wait states. It assumes that when executing MOVB @>5FF6,*R2, first a value from 5FF7 is attempted to be read, just as the TI console does. In that case, wait states are inserted if necessary. Unlike the TI-99/4A, the Geneve uses a TMS9995 processor which accesses the memory on a byte base, so it will try to read a single byte from 5FF6 only and therefore circumvent the wait state generation. If I understand the schematics correctly, the wait states are only created on the access to the odd address. I believe this could have been easily fixed by checking for the 5FF6 access directly instead of the 5FF7.

 

Maybe this was changed in later releases.

[+Ksarul]

My BwG is from the original run of 80 cards. I used it in my Geneve for several years without any issues, Michael. Note also that the 99/4A access to the PEB and its cards was also byte-based, as all 16-bit accesses were limited to the inside of the console itself. The Flex Cable interface was 8-bit.

Edited December 28, 2015 by Ksarul

[+mizapf]

The problem is not the 8 bit access but the fact that the TMS9900 always fetches two bytes, even for single byte operations. The databus multiplexer implements a little-endian order of bytes, i.e. when you do a MOVB @>5FF6,*R2, the datamux first sets the address bus to 5FF7, gets the byte, latches it, then sets the address bus to 5FF6, forwards the byte at that address to D0-D7 while delivering the latched byte to D8-D15.

 

The schematics show that when the address ends with three ones, a gate is activated that pulls down the ready line. This can only be the case for 5FF7 (or 5FFF) when accessing the WD chip.

 

On the other side, the TMS9995 has an internal databus multiplexer which actually behaves differently for byte operations. In that case, if you do a MOVB @>5FF6,*R2, only address 5FF6 will actually be accessed. Hence, I'd conclude that the wait state logic is never activated.

 

So I have two options: Say that you must be wrong, and continue to understand the circuit, or believe what you say, but wonder how the thing actually works.*

 

Currently, the BwG emulation in MAME/MESS cannot be used with the Geneve or TI-99/8 due to that issue. I could easily repair it, but then I'd have to deviate from the schematics as I understand them. Or, last option, the schematics do not reflect the state of the available cards. (Or, well, very last option, I simply misunderstood that part of the schematics, which is not so unlikely.)

 

 

(* Of course, I'd go for the latter, since I don't remember you ever telling me something wrong.)

Edited December 28, 2015 by mizapf

[+Ksarul]

It could be a little bit of both, Michael. Mine worked, for whatever reason--and adding that minor deviation to allow the 99/8 and Geneve to work with the controller in emulation might not be a bad idea either. I'd just document the specific deviation from the real hardware and explain why it is there.

[+mizapf]

By the way, the schematics can be found on the SNUG page: http://home.arcor.de/system-ninety-nine-user-group/bwg/php1245.pdf

 

Maybe someone would like to have a look? Here is a description that you may be able to follow on the schematics.

 

On the left-hand side, near the bottom, there is the data bus (D0-D7), above there is RDBENA* and READY. When READY=0, the CPU enters wait state. The tri-state buffer (U8C) delivers 0 when its control pin (pin 10) is 0. For that to happen, all inputs of U7B (OR gate up-right) must be 0. Pin 4 of U7B goes to the PAL and is 0 when the controller chip is accessed. Pin 5 is the endpoint of the signal WAITen* connected to Q2 of the U13 latch (go left from the output gate DS1* on the right side). When this bit is set, it is inverted and arrives as a 0 at the OR gate. This bit is set by a SBO 2.

 

So far, the READY line will only be lowered when a memory access to the controller is done (5FFx) and we have a preceding SBO 2. It only depends on the third input of the OR gate (pin 3). This one is connected to the output of a NAND (U23B) that gets its inputs from A13, A14, A15, and from another OR gate (U7A) whose output is inverted by a gate in between. The NAND will only deliver 0 when all of its inputs are 1. This implies that A13, A14, A15, and that OR gate are all delivering ones. The OR gate's inputs are the controller lines IRQ, DRQ, and the output of the motor monoflop, inverted.

 

So I would understand the operation as follows:

 

- The controller is reading a sequence of bits from the disk and stores them in a shift register that will be readable via the data register port (5FF6).

- As long as DRQ is 0 and the motor is turning, the data register is not ready to be read. This lock is enabled by a previous SBO 2. In order to react in time, the data register read operation must be initiated, and the processor must be locked until the byte is available. The exactly same thing is done in the TI disk controller.

- Until ready, U7A delivers 0, U23A inverts to 1. In order to arrive as a 0 at the U7B OR gate, A13, A14, A15 must all be 1. This is only possible when reading 5FF7. That is, the processor is locked while reading 5FF7.

- When the data register is full (8 bits read), DRQ is set to 1. This will arrive at U23B as a 0, the output will become 1, which eventually inhibits the tri-state buffer, and READY is released. Consequently, the datamux completes the first read operation, and the starts the second one at 5FF6.

- Now since A15 is 0, U23B will always deliver 1, regardless of the state of DRQ. The processor will not be locked during the 5FF6 access.

 

See my problem? Since the Geneve never accesses the 5FF7 address, the processor will never be locked while waiting for the incoming bits. The TI disk controller, in contrast, simply ignores the odd accesses and enters wait states on the 5FF6 address.

 

I seem to remember Michael Becker once ranting about the Geneve "doing it the wrong way, how should we know".

[+Ksarul]

I seem to remember that discussion (or a similar one) with Michael as well--he told me the BwG wouldn't work with a Geneve and I said that mine did--and would even function in 80-track mode in it. ISTR that he was not convinced either. . .

[+jedimatt42]

Anyone know if ROMPAGE in GPL or EXEC work had any issues with GENMOD?

 

I was intending to go down the path of trying out the HDX RS232 mod in my Geneve, after seeing the System review in SHIFT838 that Greg had a modded HDX serial card in his Geneve, I figured that could turn out to be handy.

 

I'm running a GENMOD Geneve, and in ROMPAGE mode of GPL, I cannot access DSK1 on my TI Stock floppy disk controller. I am setting speed to 1, before hand. My experiment is a 1 line basic program.

 

When I attempt to access the disk, some access occurs, but XB just errors with I/O ERROR 06, and TI BASIC produces error 56.

 

Does GENMOD screw with things too much for ROMPAGE to work? Or is my Geneve most likely buggered? Or does the master DSR for MDOS have patches for the TI FDC?

 

-M@

[+jedimatt42]

Anyone know if ROMPAGE in GPL or EXEC work had any issues with GENMOD?

 

I was intending to go down the path of trying out the HDX RS232 mod in my Geneve, after seeing the System review in SHIFT838 that Greg had a modded HDX serial card in his Geneve, I figured that could turn out to be handy.

 

I'm running a GENMOD Geneve, and in ROMPAGE mode of GPL, I cannot access DSK1 on my TI Stock floppy disk controller. I am setting speed to 1, before hand. My experiment is a 1 line basic program.

 

When I attempt to access the disk, some access occurs, but XB just errors with I/O ERROR 06, and TI BASIC produces error 56.

 

Does GENMOD screw with things too much for ROMPAGE to work? Or is my Geneve most likely buggered? Or does the master DSR for MDOS have patches for the TI FDC?

 

-M@

Also, to keep things as clean as possible, I'm not using any 80 track disks, as I would expect that to fail without the 80 track mod on the controller when not using the master DSR. Also tried physical floppy as well as my HFE based drive.

 

-M@

[+mizapf]

I'm not really sure ... maybe Tim can say more. ROMPAGE means that the actual DSR of the card is used instead of the GeneveOS-internal driver. If you use GENMOD you need some additional changes on your peripheral cards, if I remember correctly, because GENMOD introduces two more address lines AMD and AME. Maybe there is some issue when using the original DSR?

[+jedimatt42]

I'm not really sure ... maybe Tim can say more. ROMPAGE means that the actual DSR of the card is used instead of the GeneveOS-internal driver. If you use GENMOD you need some additional changes on your peripheral cards, if I remember correctly, because GENMOD introduces two more address lines AMD and AME. Maybe there is some issue when using the original DSR?

 

The peripheral card mods in the genmod docs weren't supposed to be necessary for Texas Instruments cards as they supposedly fully decoded those lines. But I can't help but imagine no-body in their right mind used to run a genmod with a little 40 track TI FDC either.

 

-M@

[+mizapf]

 

as they supposedly fully decoded those lines.

 

No, they only decode AMA, AMB, AMC. The two lines AMD and AME were not specified before GENMOD.

[+jedimatt42]

 

No, they only decode AMA, AMB, AMC. The two lines AMD and AME were not specified before GENMOD.

 

Ok, that gives me some hope Thanks!

[+mizapf]

Concerning these address lines, also see http://www.ninerpedia.org/index.php?title=Geneve_paged_memory_organization

[+jedimatt42]

Concerning these address lines, also see http://www.ninerpedia.org/index.php?title=Geneve_paged_memory_organization

So that write up certainly makes sense, and would possibly explain problems accessing expansion card ROMS. The disappointing part is that my actual GENMOD manual speaks of AMA AMB and AMC. It lists the illegal cards as:

All Horizon Ramdisks,

All Corcomp Controller and RS 232 Cards ( I assume that means Corcomp RS232 cards, not ALL RS 232 cards )

Some "early" Myarc DDCC-1 cards

The first 25 Rave Speech Cards

 

This might have been fine before ROMPAGE was a GPL feature. I haven't been able to figure out which came first.

 

Is there any documentation known on actually modding expansion cards to only respond to the required AMD & AME state?

[+InsaneMultitasker]

ROMPAGE is fairly simple. In TI Mode (GPL) the Geneve master DSR (memory page 0x07) is mapped into the 0x4000-0x5fff space. All DSR calls are routed to this page, and the DSR handles the complexities behind the scenes.

 

When ROMPAGE is executed, memory page 0xBA is mapped into the 0x4000-0x5fff space. A partial or full powerup is executed to reset the cards to a "TI" operating state. As a result, the external bus is visible to the Geneve, and peripheral calls are handled by the peripheral DSRs.

 

I am not aware of any AMD/AME decode requirements. Only AMA/B/C need to be decoded as documented in the Genmod requirements. If there was a problem with the Genmod, your peripherals would fail at all times, not just ROMPAGE mode, so I wouldn't get too concerned about this 'failure'.

 

What I recall is that the MEMEX card has a DIP switch setting to lock out certain pages, including 0xBA. Check the documentation and compare the switch settings. If you don't have the docs, I'll try to dig them up in the near future.

 

Assuming you get things working, experiment with the speed setting before using SPEED 1. I don't think the TI and CorComp FDCs are sensitive to the speed settings. Only the Myarc DSR has a timing loop versus polling, which requires a speed drop to read/write disks. A standard Geneve and Myarc FDC combo usually operate fine at speed 3 during a ROMpage. (Since EXEC doesn't have a speed setting, GPL is often preferred when using ROMPAGE and a Myarc FDC. )

[+jedimatt42]

I found the MEMEX docs on WHTECH. Thanks, I'll experiment with that.

[+InsaneMultitasker]

I have a Genmod w/Memex, alas it is flakey. If through experimentation ROMpage will not function properly, I may be able to test it here.

 

Additionally, if you have SBUG or the Minimem cart dump, you can load the cartridge (in GPL), execute ROMpage, start the debugger, turn on CRU bit 0 at 0x1100 (floppy controller), and inspect the 0x4000 space. You should see the DSR header starting with >AA.

 

good luck

 

 

Edit: I just remembered I do not have the switchbox. Check the Genmod docs for proper switch orientation, as that may also have an impact on how the Geneve is seeing those pages.

Edited April 17, 2016 by InsaneMultitasker

[+jedimatt42]

How fortuitous that I just received a mini-memory cart package in the mail yesterday. At a memory cost rate of $7.8 million per gigabyte, luckily it only has 4k.

[+arcadeshopper]

That

 

Anyone know if ROMPAGE in GPL or EXEC work had any issues with GENMOD?

I was intending to go down the path of trying out the HDX RS232 mod in my Geneve, after seeing the System review in SHIFT838 that Greg had a modded HDX serial card in his Geneve, I figured that could turn out to be handy.

I'm running a GENMOD Geneve, and in ROMPAGE mode of GPL, I cannot access DSK1 on my TI Stock floppy disk controller. I am setting speed to 1, before hand. My experiment is a 1 line basic program.

When I attempt to access the disk, some access occurs, but XB just errors with I/O ERROR 06, and TI BASIC produces error 56.

Does GENMOD screw with things too much for ROMPAGE to work? Or is my Geneve most likely buggered? Or does the master DSR for MDOS have patches for the TI FDC?

-M@

 

When you rompage it sticks the emulated disk in front of real drives.. Geneveos supports an emulated disk image .. SO DSK1 is now DSK2