Geneve Questions!

[+mizapf]

Well ... these are the frustrating moments of emulation. ?

 

I never got the BwG to run with the Geneve emulation. It does run flawlessly with the TI-99/4A, and all other controllers including the DDCC-1 are working, but not the BwG with the Geneve. Of course, when I first observed these issues, I did a lot of debugging and error tracking, and finally I could say it was obvious and *provable* that the BwG would not run! ? So let's forget reality for a minute.

 

I'll detail my thoughts below. Maybe someone can tell me where I am wrong. (The others may learn how a disk controller works. )

 

I got the schematics of the BwG and checked how it worked. This is the relevant part that I attach to this message. It shows the "READY trap".

 

From left to right:

- READY is pulled down when U7B outputs a 0. As it is an OR, this means that all inputs must be 0.

- The lower violet line is the "SBO 2" line. When you execute SBO 2, the bit is first inverted, then routed to U7B as a 0. Hence, without SBO 2, there is no lock.

- The blue line goes to U23B (NAND). It must also be 0, which means that all inputs must be 1.

- One of the inputs is A15. Thus, we must have an access to an odd address, and it must look like ...7 or ...F (because of A13=A14=1). The data register of the WD1773 is mapped to 5FF6 (read) and 5FFE (write). What we don't see here (clipped by me) is that the other address bits are checked to be 5FF...

- Pin 9 of U23B gets its input from U23A (configured as an inverter) and then from U7A. To be 0, all inputs of the OR must be 0. One input is from U24A, the motor monoflop. This means that if the motor stops spinning, the lock is immediately released. The other two are IRQ and DRQ from the controller chip WD1773. Both are high active; if some exception occurs, IRQ will be asserted, and when a data byte has been gathered and is now available in the data register, DRQ is asserted. In both cases, the lock is released.

 

Now we have a look at the DSR:

8300:     MOVB @>5FF6,*R2
8304:     DEC  R6
8306:     JNE  >8300
8308:     RT

 

This is the typical loop that we also have in the other WD-like controllers (not in the HFDC; it does not need a READY control, as it uses its on-board RAM to let the controller push the data into it).

 

This part has been copied to 8300 before the operation. In the first line there is a byte read from 5FF6. This is a even address, so it does not set A15 to 1. However, the TI-99/4A always reads the odd address first, then the even address. It reads 5FF7, and locks up. Meanwhile, the controller gets a byte, signals via DRQ that the byte is lying in 5FF6. This releases the READY line, the CPU continues, reads 5FF7 (which is masked away from the controller at another part not shown here), reads 5FF6, and so gets the byte. R6 is counted down until there are no more bytes to come (we are reading a whole sector). R2 is actually >8C00 (VDPWD), so each byte is copied to VDP memory.

 

Now, as I said, the emulated BwG fails to work with the emulated Geneve. This is perfectly understandable with the explanation above: The Geneve only does single byte accesses, so it does not access 5FF7, and the lock is not activated. Instead, it spins down all 256 iterations immediately. Sometimes you are really glad when you've found a plausible explanation after all.

 

But why on Earth are there BwG that are working with the Geneve??

 

One thing could be that there was a revision of the board. It was not necessary to wait on the odd address; the even address 5FF6 would have done, too. This is the way how it is done in the TI FDC and the DDCC-1. I do not know why the SNUG people went for that way in the first place.

 

I thought it could suffice to cut the A15 line at U23B and to pull it up. In that case, the lock would have been activated twice, for 5FF6 and 5FF7. However, when the Geneve reads 5FF6, this also clears the DRQ, and the lock could be activated again, so it could be trapped. The TI-99/4A would not have this problem, since it first reads 5FF7, which does not affect the controller. I tried it in MAME, but it did not have an effect (which is less than expected); need to continue working on that.

 

Or maybe the DSR was modified. If the MOVB were replaced by a MOV, the Geneve would also do a two-byte operation, triggering the trap.

 

I'll keep you informed. Until this is settled, I keep the BwG removed from the possible choices for a disk controller for the Geneve.

[+InsaneMultitasker]

19 hours ago, mizapf said:

There is no fatal hardware deficiency, otherwise GeneveOS would not be able to use the controllers by its master DSR.

Perhaps then the issue is truly in the controllers' EPROM DSRs.  Sometime earlier this year, source for the TI FDC DSR was posted.  I haven't been able to locate that post or topic, but I seem to recall there were a few instructions labeled as 'delays' for one or more operations.  If the HOLD hardware is of no concern, that is promising...

[+mizapf]

I'm starting to get some doubts. I just had a look at the boot EPROM (comments from me):

 

0864:     MOVB @>5FF0,R4      Get status from controller
0868:     INV  R4         Invert it (FD1771 has inverted bus lines)
086A:     JLT  >0874        First bit set = NOTREADY
086C:     COC  R8,R4       R8=0200; DRQ bit (mirrors DRQ output)
086E:     JEQ  >0882       If set, DRQ output=1; there is a byte
0870:     COC  R9,R4       R9=0100; BUSY
0872:     JEQ  >0864       If set, command is executing
0874:     JMP  >07CA              Error

0876:     MOVB @>5FF0,R4    see above
087A:     INV  R4
087C:     JLT  >0874    NOTREADY
087E:     COC  R8,R4
0880:     JNE  >088C   DRQ
0882:     MOVB @>5FF6,R4   Pick up byte from register
0886:     INV  R4           Invert it
0888:     MOVB R4,*R3+    Copy it into memory
088A:     JMP  >0876
088C:     COC  R9,R4    BUSY
088E:     JEQ  >0876
0890:     JMP  >082E

 

Despite my first guess, the boot EPROM is actually polling the DRQ state. This would mean that it does not rely on the READY trap - otherwise, it would suffice to execute the instruction at 0876 or 0882 (as done in the original DSR).

 

One thing that just came to my mind:

1. When code is executing in on-chip RAM, the READY line is always ignored. This is not on-chip RAM, so it's not the point.

2. The original DSR assumes that logical addresses 8300-83FF are mapped. As it seems, one SRAM page is mapped there, so this should be good either.

(two things)

 

So why didn't they rely on the card hardware? The problem is that the READY line is fed into the Gate Array first, then into the PAL, then into the CPU.

 

3. The boot EPROM (I'm always talking about 0.98, just to be clear) probes different cards. I see references to Myarc cards, the original TI controller, and Corcomp. I have to check what it does when the BwG is plugged in.

 

If the READY trap does not work, my considerations from the previous post are probably irrelevant.

[+mizapf]

OK, I had a closer look at the boot EPROM (0.98).

 

It does the following check:

- Look for a card with the device "HD". If found, try to load SYSTEM/SYS from it. (Horizon RAMdisk)

- Look for a card with the device "WDS". If found, try to load WDS1.DSK1.LOAD/SYS. If that fails, try DSK1.LOAD/SYS. If that also fails, error out. (Interestingly, this is the only device that is rompaged and that is allowed to use its own DSR.)

- Now try CRU >1100 only. Check if there is a card; if not, error out.

- Try to write a word to >5000; if that succeeds, we have a Myarc floppy controller (DDCC-1).

- If that failed, set CRU bit 11. If we have a CorComp, this would map the upper bank into >4000.

- If there is still AA at >4000, it is a TI FDC, else it is a CorComp.

 

The point is that a BwG ends up to be detected as a TI FDC. However, it uses a different controller (WD1793 instead of FD1771). The FD1771 controller has inverted bus lines, so every byte must be inverted before writing or after reading. This is wrong for the WD1793.

 

This would again prove that the BwG cannot boot the Geneve, at least with the 0.98 boot EPROM. I have to concede that I am running out of ideas now ... ?

[+InsaneMultitasker]

33 minutes ago, mizapf said:

- Look for a card with the device "HD". If found, try to load SYSTEM/SYS from it. (Horizon RAMdisk)

This always bugged me until I found an old document referencing the Horizon EPROM and the use of a "HD" device name.  The older Geneve boot eprom used the DSR subroutine to boot from the Horizon whereas the most recent 0.98 uses direct CRU access (and only a few bytes from the copied dsr code is used to detect the card).

 

Returning to the TI and CorComp cards, is it reasonable to infer that the lack of READY trap is why the boot eprom contains low level IO routines for those two controllers?  

 

IIRC, the Myarc FDC DSR runs too quickly at full Geneve speed. The card will operate in GPL w/Rompage at lower speeds but speed 5 results in disk read failures, at least with my system. I suppose this could explain why the Myarc FDC low level IO is also on the boot eprom. And of course the added benefit for all three floppy controllers is the fastest possible boot times.

 

The IDE, SCSI, and HFDC cards all load via their respective DSRs/rompage via the sector IO routine >80 and >20.  Some day I should compare performance between the sector IO and direct read IO (>84, >24) operations.

 

33 minutes ago, mizapf said:

- If that failed, set CRU bit 11. If we have a CorComp, this would map the upper bank into >4000.

- If there is still AA at >4000, it is a TI FDC, else it is a CorComp.

Years ago, a user with a BwG card told me that his card was detected as a CorComp. I am wondering how this is possible. Is the BwG emulating CRU bit 11 to mimic its bank switch?   @OLD CS1 was operating a Geneve with the PFM+ device. I suppose the PFM detection routine could be different, however, it wouldn't explain the Geneve OS detection which is the same as what you describe...

* here, check to see if ti or corcrap
*
NOTMYR MOV  @H9FF0,@CTLBAS
       MOVB @H00+>2000,@CTLTYP
       SBO  11
       CB   @>C000,@HAA+>2000
       JEQ  PWREX             it's a ti card (use 40 track, step setting=2)

 

 

 

[+dhe]

fwiw - I was told by Michael Becker, that the Geneve see's and uses the BwG (Becker, Winters - with a small w because he promised to help with the  work and design, but didn't, Glaab(sp)) as a Corcomp disk controller.

 

[globeron]

@mizapf  not sure it helps, but one of my BwG disk controllers went to Italy during the sale, but I still have one with me running in a TI system.

 

 If I remember correctly both had a different Eprom version. For the Geneve I am usingnow a Corcomp controller and guess I switched it because of the issues (besides the other issues I had to get the Geneve to work). Let me check the version of BwG later tonight.

 

With 0.98 boot eprom (Swan) you mean Geneve correct? Not BwG.   My Geneve has the non-Gen mod eprom.    

 

 

[+OLD CS1]

Real iron, my Geneve works very well with my BwG, better than the CorComp Myarc DDCC-1 (admittedly, not factory as it has the 80-track DSR.)

Edited November 21, 2020 by OLD CS1
I keep saying I have a CorComp DSDD controller... it's like a tic with me...

[+mizapf]

@OLD CS1, could I send you a dump program that creates a disk dump of your boot EPROM and the BwG ROM? Just to make sure whether we have a patched version somewhere.

 

In fact, if the BwG is detected as a Corcomp controller, it should boot the Geneve, because both are using the same controller chip (WD1793). The only problem is when the BwG is falsely detected as a TI disk controller, because the FD1771 controller has inverted data lines, so every byte you get or send to it must be INVed, and this must fail for the other chip, I am quite certain.

 

Yes, and 0.98 is the usual "Swan" release with black border.

[+OLD CS1]

2 hours ago, mizapf said:

@OLD CS1, could I send you a dump program that creates a disk dump of your boot EPROM and the BwG ROM? Just to make sure whether we have a patched version somewhere.

I have taken my Geneve system apart at the moment.  I will let you know when I can do this.

[globeron]

On 11/21/2020 at 7:44 AM, globeron said:

@mizapf  not sure it helps, but one of my BwG disk controllers went to Italy during the sale, but I still have one with me running in a TI system.

 

 If I remember correctly both had a different Eprom version. For the Geneve I am usingnow a Corcomp controller and guess I switched it because of the issues (besides the other issues I had to get the Geneve to work). Let me check the version of BwG later tonight.

 

With 0.98 boot eprom (Swan) you mean Geneve correct? Not BwG.   My Geneve has the non-Gen mod eprom.    

 

 

@mizapf this version runs in my TI. Can the eprom dump program be used here or does it need to run in the Geneve?  I also have the mini eprom tl866 device if it helps to dump.

 

It seems there are two chips that are updated.

 

Edited November 22, 2020 by globeron

[+OLD CS1]

FWIW, my BwG EPROM is marked v1.18.

[+dhe]

FWIW - https://www.s-n-u-g.de/bwg/index.php

 

 

 

 

 

 

bwg.zip

[+mizapf]

What I can imagine is that the BwG controller (by its GAL) was modified to pretend to be a Corcomp. It would suffice to turn off the DSR ROM when CRU bit 11 is set. The Boot EPROM only checks whether setting bit 11 has any effect, i.e. it reads 4000 again, and when there is no AA anymore, it sets the Corcomp flag.

 

The actual ROM contents are less relevant, as the boot EPROM does not pass control to it.

[GDMike]

I'm writing code that uses SAMs on the 4A, so, of course, Im using a super AMS PEB card. 

Do I have to pull that card prior to installing the Geneve card? And is the memory on the Geneve enough to do anything with? Because I don't have any other memory or ramdisk in the PEB.

I do have TIPi though.

Thx

[+arcadeshopper]

I'm writing code that uses SAMs on the 4A, so, of course, Im using a super AMS PEB card. 

Do I have to pull that card prior to installing the Geneve card? And is the memory on the Geneve enough to do anything with? Because I don't have any other memory or ramdisk in the PEB.

I do have TIPi though.

Thx

You can't have any other memory than Geneve memory it has onboard ram that GPL uses for the VDP and CPU RAM of the 4a including the 32k expansion. The rest of the Geneve RAM is used for the GPL program and mdos so it isn't available in timode (GPL)

 

Other add-on Geneve memory includes the memex board and modified Myarc 512k boards. Both are in short supply.

 

The only way to access that memory is through native programs running in mdos.

I'm not entirely sure if you can access additional memory in abasic but I'm relatively sure that you can access more program space with it since it runs natively in mdos.

 

Greg

 

Sent from my LM-V600 using Tapatalk

 

 

 

[+9640News]

13 hours ago, GDMike said:

I'm writing code that uses SAMs on the 4A, so, of course, Im using a super AMS PEB card. 

Do I have to pull that card prior to installing the Geneve card? And is the memory on the Geneve enough to do anything with? Because I don't have any other memory or ramdisk in the PEB.

I do have TIPi though.

Thx

You need to remove the AMS as well as the Flex cable card.  The minimum cards you need have in your PEBox is the Geneve and a floppy disk controller.  You can add a RS232, HFDC, SCSI, Memex Memory card, or a Myarc modified 512K card.  There is a source for unmodified Myarc 512K cards if the guy hasn't finished selling out his supply (new).

 

As far as Geneve memory you could in theory have around 1.4 MB of memory to play in the 4A environment using the map registers.  However, you have to worry about memory conflicts if on the MDOS side of things you have configured ramdisks or have other "drivers" installed.  It is easy to overcome, you 

 

You still have in a "normal" GPL mode environment, extra memory beyond the normal "32K" ram space more ram that is immediately available to GPL without special coding to find the memory.  I took a quick look and I think you may have somewhere around 80K of ram you could use besides using the 128K/192K VDP ram for use.

 

Beery

 

[GDMike]

Ok, I've finally got a 1st boot in 30 years video.

I'm also working on getting a video adapter made by Chris.

[GDMike]

My success was short lived.

I cut out the power LED and soldered a new one on the old pins. The led lights now and I saw flickering of LEDs on the keyboard this time power up.

BUTtttt. No more boot to floppy.

Not even a flicker of led on the controller light.

So I cleaned contacts again, I reseated the card and always the same results, no boot from floppy.

So I tried another port in the Peb and same results.

I noticed that one side of the bank of ram are a lot warmer than the other.

Anyway, I don't have a scope or bench to do any real diags.

 

1st boot video and after led swap video.

Btw. I tried disconnecting the LED again just to see if it made a difference.

I also pulled the 32K ram upgrade I did,, and I put in a new 32K just by itself and nothing changed.

I put the ti and pen back together and the floppy drive is fine and everything works..thank God

Edited November 26, 2020 by GDMike

[+InsaneMultitasker]

26 minutes ago, GDMike said:

My success was short lived.

I cut out the power LED and soldered a new one on the old pins. The led lights now and I saw flickering of LEDs on the keyboard this time power up.

Did you replace the regulators and/or add heat sinks, as recommended in the Myarc repair thread?  As I recall, the card has stock regulators which were prone to failure, especially when installed as shown in your earlier pics. 

[GDMike]

Just added heatsinks, a battery holder with new battery and the 32K sram.

One thing that has happened.

My original peb is

interface card

SAMs card

Tipi pen card

TI floppy card

All was working well prior

Now while putting it back together, the floppy controller lights at boot but doesn't respond from the ti.

I removed the tipi and then the disk controller works.

This wasn't the case just mins earlier.

 

Edited November 26, 2020 by GDMike

[GDMike]

I'm going to see if changing the address on the tipi to revive my system

[GDMike]

I'll have to wait till after the holiday.

Edited November 26, 2020 by GDMike

[GDMike]

I had a moment to change my base tipi address and everything is working again on the TI-99 side., Tipi, ti controller, SAMs 

Geeesh.. I thought I killed my system for a moment.

I need to find someone to look the Geneve card over and see what is going on.

You never know what these cards can kill when you try booting them up.

 

[GDMike]

I've been working with Greg in the background we decided to pull the floppy disk controller out of the PEB and use the tipi and map a couple more drives.  and it all worked fine, so definitely a bad floppy controller card. I bet you there's nothing wrong with the Geneve card at all.

And the seller said it worked last time he had it. but you never know. and the LED didn't work.. did it but now it does after I changed it. The keyboard flashes like it's supposed to, so I bet you the Geneve is okay. But I'll let Chris look at it just to verify.

Edited November 26, 2020 by GDMike