What if? Designing "Geneve 2020". Cool 3D views!

[+TheBF]

9 minutes ago, FarmerPotato said:

Incidentally, while traveling, I've made baby steps on a MAME Geneve 2020... So I can test out Forth.   I begin with the 99/4A + my boot ROM, rather than with the Geneve driver. In some ways, the 16-bit bus 9900 is closer than the 9995, to the target 99105.

As always, I can't promise dates. "December" board has not been manufactured yet, and it's definitely not the final one. Though that design does include the support that GeneveOS needs.

funny you should mention...

 

I just got code working that does AUTOBAUD  selection from 110...38400 bps. 

Of course the "mark/space"  timings are for TI-99 expansion RAM so they would need to be changed for your machine but it works!.  

I will be publishing the code over on Camel99 thread.

[+FarmerPotato]

9 hours ago, TheBF said:

funny you should mention...

 

I just got code working that does AUTOBAUD  selection from 110...38400 bps. 

Of course the "mark/space"  timings are for TI-99 expansion RAM so they would need to be changed for your machine but it works!.  

I will be publishing the code over on Camel99 thread.

Auto baud is a cool trick that seemed like magic to me.

Recently I've found TI's commented source code for baud rate detection, in the TM990/189 manual and several other places.  They use the 9901 timer.

 

I haven't worried about baud rate. Fixed 9600 suffices for my testing. 
 

 

 

[+dhe]

Hey @FarmerPotato!

     Fall has arrived.

 

  Can you give us an update on the status of the Geneve 2020 project?

[+FarmerPotato]

On 9/30/2023 at 6:44 AM, dhe said:

Hey @FarmerPotato!

     Fall has arrived.

 

  Can you give us an update on the status of the Geneve 2020 project?

It is still stuck in December--the "December" stand-alone board, which I've been editing since last December.   My weakness is tweaking the board, or running simulations. ($100+ shot to build the thing)  Not taking the shot to send it to the PCB factory, build and debug it.  

 

Life is such that I don't get a whole day to focus on it.  Or I go to VCFSW, pick up a TI 990/12, then spend my time fixing up a TI 928 terminal to connect to my board... Made the (untested) Forth interpreter, needed for debugging the board. 

 

I uploaded the PCB last week to aisler.net.  Today the price is less, $24 x 3, for the 4-layer (4-slot) backplane, $14 x 3 for the CPU. 

 

 

[jbdigriz]

10 hours ago, FarmerPotato said:

It is still stuck in December--the "December" stand-alone board, which I've been editing since last December.   My weakness is tweaking the board, or running simulations. ($100+ shot to build the thing)  Not taking the shot to send it to the PCB factory, build and debug it.  

 

Life is such that I don't get a whole day to focus on it.  Or I go to VCFSW, pick up a TI 990/12, then spend my time fixing up a TI 928 terminal to connect to my board... Made the (untested) Forth interpreter, needed for debugging the board. 

 

I uploaded the PCB last week to aisler.net.  Today the price is less, $24 x 3, for the 4-layer (4-slot) backplane, $14 x 3 for the CPU. 

 

 

Yeah, I could use a case or two of focus here sometimes. Too many projects is not the worst problem in the world to have, though. Take your time and do it right.

Edited October 3, 2023 by jbdigriz

[+FarmerPotato]

The boards are uploaded.  "December" est. delivery next week.  Backplane, maybe slower, it's 4-layer.

 

FRONT

 

 

BACK

 

 

FRONT+BACK

 

 

BACKPLANE

 

 

 

[+Vorticon]

So this looks like a standalone computer at this point? 

[+dhe]

My understanding is, that it was always was intended to be so - so it breaks constraints of old hardware, and old bandwidth limitations.

[+FarmerPotato]

It actually started as a board to fit the 4A console shell!

Dan is correct about bandwidth: where do you put a 16-bit bus in the P-Box , without breaking everything? I was attracted to TI's 32-bit NuBus. 

I figured on building a P-Box interface later, as  a NuBus card. So it could operate your peripherals.
 

At that stage, It's not impossible to imagine adapting the Geneve 2020 CPU card to just live inside the PBOX...

VDP and sound are separate cards. But I think it worthwhile, to adapt those to be PBOX cards. A new 9958 video card with VGA output. 

Not promising anything.  That's over the horizon. First finish and debug CPU, video and audio,  using TI's  NuBus backplane. (That's also easier and more enjoyable to test.) 
 

[+FarmerPotato]

"December"'s hardware abstraction layer (HAL) is flexible enough to map any CPU or CRU address to onboard, offboard, or a software interrupt.

The overriding goal is perfect emulation of 4A or 9640 hardware. Those features are enough to do it. 

 

While 9640 or GPL see only 8-bit memory map registers, the LS612 map registers are 12 bits wide, with the other 4 controlled by the HAL. This allows 32 MiB total: 

 

0000 0000   2 MiB  onboard
001F FFFE

0020 0000  28 MiB "uncommitted" NuBus space
00DF FFFE

00E0 0000   2 MiB fixed-address NuBus "slot space".  
00FF FFFE

 

2 MiB onboard, configured as 9640 memory map (or otherwise) when the BIOS loads GeneveOS. "Holes" opened up for memory-mapped I/O or peripherals, according to CRU bits MODE_MDOS and MODE_GPL. 

28 MiB "uncommitted" NuBus space-- flexible addresses assigned to cards at startup. (Eg a large memory)  Mapped to low end of NuBus. 

2 MiB dedicated "slot space".   Mapped to high end of NuBus in 16 chunks that correspond to its physical location on the backplane. 

NuBus slots have 4 ID pins, which tell a card which slot it's in and what address it has.  I added a CARDSEL signal to each backplane slot, and a decoder on the backplane.   So cards can omit address decoding circuitry, if all they care about is to respond at their slot.  

 

That 32 MiB maps into the 32-bit NuBus like this:

 

0000 0000  CRU access to a well-known off board device, such as joysticks  
     7FFE
0000 8000  Off-board access to a well-known memory-mapped peripheral, such as VDP at 8800 or F110
     FFFE

0020 0000  Uncommitted address space
00DF FFFE

00E0 0000  Unimplemented address space

F000 0000  Slot 0 CRU space
F000 8000  Slot 0 Memory-mapped I/O ports
F001 0000  up to 64K DSR ROM
F001 FFFE

F100 0000  Slot 1 ...
F700 0000  Slot 7 ...
FF00 0000  Slot F

 

 

 

[+Ksarul]

Rave99 actually tried to extend the regular PEB bus to 16 bits by adding an option for an additional connector for each card slot. The only card that ever used it was their compatibility card to move the console motherboard into their PE2 expansion box. SNUG went a different route and ran a flat cable across the tops of their cards to add 16-bit capability to the bus. The SGCPU and the HRD16 are connected this way.

 

There are ways to do this that don't break compatibility, but the real test of the best way to do it is your use case. Yours seems to be a bit different to what the other two solutions were trying to do, which is OK if it meets your needs. Your hobby--your solutions. I respect that.

 

 

[Tornadoboy]

So how long until I can build one of these things? 

 

Are the Gerber files going to be made public? 

[+FarmerPotato]

More Memory Mapping in "December"

 

In GPL or MDOS mode, many addresses are recognized as memory-mapped ports (NOTE) or CRU devices.  This is done in a "Recognizer" chip.  It performs many functions of the Gate Array in Geneve 9640. 

 

When the Recognizer recognizes an address, it emits a code, and asserts SPAMM* if it should go off-board.  SPAMM* causes the External Bus Logic to pass them to the external bus with slot 0, where any card may respond to them. (This is a temporary kludge.  Until I create a bigger mapper. The Recognizer will then have the full card address.)  

 

Slot 0 is the CPU anyway. But also slot 0 may be sometimes the front panel ports, which are the keyboard and stuff.    It's another kludge.

 

NOTE: some ports are memory-mapped - the Recognizer chip asserts SPAMM*... or the much more boring name MMIO*.  

 

 

Examples of Recognizer Chip doing device mapping:

 

From Logical CPU address:

 

8000 goes to the memory mapper if MODE_GPL

8800 goes to the VDP if MODE_GPL.  Etc

F100 goes to the onboard memory mapper if MODE_MDOS.  Raises FAULT to invoke supervisor interrupt

F110 if MODE_MDOS, goes to the off-board VDP, Etc.

F120  ditto for sound, keyboard, clock

F130 "

 

From CRU address:

 

CRU 0000 maps off-board to the joysticks, keyboard decoder/encoder etc.

CRU 1300 bit 5 maps to onboard LS259 register for CTS1 pin

CRU 1340 maps to onboard 9902

CRU 1FD0 decodes to external instructions, like RSET, or LREX (which activates the single-step circuit)

CRU 2000 maps to onboard 9901 (privileged address)

CRU 2100 maps to onboard LS259 for miscellaneous LEDs etc.

CRU 2200 maps to onboard FRAM for non-volatile memory, BIOS config etc.  This stupid experiment distracted me.  

CRU 88xx or F110 goes to the VDP card. Etc

CRU 98xx off board to GROM emulator

CRU F100 goes to the onboard memory mapper

 

Many devices have a twin CRU address. Which happens to match the usual 4A address. 

 

Recognizer also does the courtesy of suppressing a READ-before-WRITE on MOVB R1,@VDPWA and the clock chip.  The 9900 and 99105 do read-before-write (99105 only on byte operations). 

Not Recognized Addresses:

 

CRU <magic> assert FAULT* on certain magic Gate Array bits, handle in software

CRU 1sxx map off board at slot s, or if bit 0 they raise FAULT , to toggle in MODE_GPL/MDOS, to map in/out the DSR ROM page
CRU E100 is a shortcut to external slot 1 memory-mapped ports.

 

Not Recognized in "December", because STOP ADDING NEW FEATURES:

 

Recognizer may partly decode the 9900 instruction field, detecting BYTE operations or parallel CRU byte or word (this is hardcoded in the instruction field for parallel CRU) . It asserts MEMWIDTH* if it is an 8-bit transfer, else 16 bit.   The External Bus Logic asserts the NuBus code for an 8 bit or 16 bit transfer (no 32!).  VDP card may take 8 bits, or latch & multiplex a 16 bit word.  This is an idea from TI Bedford's  E-Bus Systems Handbook.  

 

Not Implemented in "December"

The front panel connectors are not wired into the CPU card. They are a separate card soldered onto the backplane!  PS/2 keyboard, mouse, TI/Atari joysticks, others.

Instead, they are treated as off-board, in Slot 0.  But the CPU is also in Slot 0.   Effectively, there are 2 cards plugged into Slot 0: a CPU, and a front panel. 

 

So while I wait for the PCBs to come back, I'll pick up the work on the keyboard and front panel. 

 

 

[+FarmerPotato]

29 minutes ago, Tornadoboy said:

So how long until I can build one of these things? 

 

Are the Gerber files going to be made public? 

 

I expect to post the whole KiCad project.  It is the "reference manual."

 

No promises about the delivery date.  I have amassed parts to make kits. 

 

 

[+FarmerPotato]

41 minutes ago, Ksarul said:

Rave99 actually tried to extend the regular PEB bus to 16 bits by adding an option for an additional connector for each card slot. The only card that ever used it was their compatibility card to move the console motherboard into their PE2 expansion box. SNUG went a different route and ran a flat cable across the tops of their cards to add 16-bit capability to the bus. The SGCPU and the HRD16 are connected this way.

 

There are ways to do this that don't break compatibility, but the real test of the best way to do it is your use case. Yours seems to be a bit different to what the other two solutions were trying to do, which is OK if it meets your needs. Your hobby--your solutions. I respect that.

 

 

Yeah I had lots of motivations and interest in other directions.   I guess there could be a second edge connector on a PBOX card.  Had not considered that.  I did not know about RAVE and SNUG having extra connectors.  
 

I got the motivation to base it on the DIN-41612 standards ("EuroCard"), from the ECB (N8VM) community.  And also the E-Bus Systems Handbook.  TI's NuBus standard IEEE-896 adopts all of DIN-41612 physical card dimensions and all.

 

From there, it was natural to use TI's NuBus backplane, which was all DIN-41612 in the first place. 

These are some things I studied with multiple connectors:  In 1980, ERNI had their EuroCard 9900 system plugged into one bus connector, and plugged into a second connector for mostly analog rails.   TI's 32-bit NuBus has 96 pins, but their S1500 and Explorer machines had two lanes of it!  So 96 extra, uncommitted pins from the start!!!  VMEBus has up to 3 connectors with 96 pins each.  CPCI or PXI kept making the connector longer until they got to 160 pins, then I lost track.  Apple never did that, except there is maybe one case of a Macintosh II NuBus pro card that took up two slots and had a bridge bus on top. 

 

My Geneve 2020 enclosure is inspired by a PXI modular test equipment rack, an Altair 8800, and the P-Box.  

 

 

[+FarmerPotato]

Geneve 2020 changed planes in Geneva:

 

Th, 19.10.2023, 12:01, Aachen, Germany
Th, 19.10.2023, 18:40, IPZ Frankfurt
Fr, 20.10.2023, 21:41, Frankfurt am Main Airport, Germany
Mo, 23.10.2023, 00:45, Geneva Cointrin International Airport, Switzerland
Mo, 23.10.2023, 07:44, New York Airport, United States
 

[+FarmerPotato]

 

The PCBs arrived on Friday.  

 

Outside of the 4 TMS99xxx chips, these boards are surface mount components: I stuck to 1.27mm SO and SOIC, with 0805 caps and resistors, except for one tiny TSSOP voltage regulator, TLV75533 for the 3.3V parts.

 

This is my first time using a reflow oven.  It's an old toaster oven.   Just turning the knob by hand, I've got it pretty close to the recommended temperature/time curve.  

The most difficult part was going to be the surface-mount PLCC-32 sockets which hold 128k EEPROM.  To test it, I used an old board with surface mount PLCC-28.  Satisfied, I did one PLCC-44 on the real one (you know why they send you three boards!) That one had several solder bridges to fix.  I had to learn the correct amount of solder paste. 

 

This bake, I got 3 of 3 PLCC sockets perfectly aligned, no bridges.  Unfortunately, the socket-with-too-much-solder has sailed away, sailed away.  It crashed into an ALS573 latch.

 

 

[+FarmerPotato]

TI MSP430 LaunchPad with  Booster Pack ADS1118. 16 bit ADC with thermocouple. I picked this up many years ago when the LaunchPad was $4.30. 
 

I imagine reprogramming the LaunchPad 🚀 demo to control the oven temperature/time cycle.  But just having the temperature readout works for now.
 

The demo lets you set the temperature and time limits. The alarm it makes is like a smoke alarm, so I did NOT set the limit for 235 C (the top of the solder curve).
 

 MSP430 is a neat little CPU. 

 

(Needed case, found TIPI)

[+FarmerPotato]

Last night, I decided to fix the reflow accident, rather than start over with PCB 2/3.

 

It did not go well. I warmed it up. Saw the solder melt. The PLCC-28 came off, but so did one pad and 10 mm of trace.

Lifted Traces

New situation for me. Start over or fix?
 

I spent an hour gently "petting"  the trace back into place.  "Microscope" ($100 webcam type) on maximum zoom.  Got the mangled trace looking pretty good again. Got the pad tinned--then the pad broke off. Shoulda given up.
 

Since the pin is ROMEN, I decided to bodge wire the two EEPROM  sockets' ROMEN. (MSB, LSB for 16 bits.) Looks good:  teeny wire slips under the PLCC-28, emerges, a dot of solder paste and done. I love sharp tweezers. Later I'll do the other end.
 

Then I removed the ALS573 latch. One pad lifted up: AD8. (CPU multiplexes address and data on AD15:0. Use '573s to latch the address.)

 

I "petted" the trace down and  decided to solder two corners of a new 573, then fix AD8. Got a solder bridge from AD9 to AD8's twisted pad.  Then the trace broke off, so I put a teeny wire from AD8 to its via.
 

I couldn't  be sure of a good solder joint to the via. Oh well. Amanda gave it a try. She even got the wire tip down into the via, with a solder ball on it. Tried clear liquid flux (ChipQuick, but dated 2019.) Then the wire came off the pin. We gave up. 

First time I'm repairing lifted traces. Got a bunch of XP with tiny wires. Big lesson: just start over.

 

But I probably won't.

 

Next: bodge wire from the CPU AD8 to the '573 address latch.

Thinking now of the earlirst electrical test.  Does the 99105 correctly access bytes from both EEPROM? That will tell if the bodge is good. If not, I should start over. 

Edited October 31, 2023 by FarmerPotato

[+FarmerPotato]

All fixed up with bodge wire. Continuity checks out. 

[+FarmerPotato]

Soldering complete for main feature set. Completed continuity and shorts checks. Soldered SOJ-36 512K RAM  on first try. First power up: rails good. The 3.3V regulator lights up its LED. (TLV75533 is the only 0.95mm part.) 
 

Two goof-ups in PCB:

SOIC and SO sizes are confusing at 16 to 20 pins. SOIC-16 << SOP-16 
SOIC-20 >> SOP-20. 

Got these wrong way round for the LVC245 and ALS259B.  Forced wide LVC245 to fit narrow footprint. Gave narrow ALS259B eight tiny wires to reach the pads. 

I had axial caps in 1 and 10 uF, but designed for radial caps. Made them fit, in spite of risk of shorts. 

I assumed a 3 MHz crystal for the 9902 & oscillator HC04. 3 MHz is not a common value!  However because CPU may run at 3 or 6 MHz, I have a clock divider for the 9901 to get 3 MHz from either  CLKOUT or CLKOUT/2, whichever is  3 MHz. Works  for the 9902 too. 

My red and yellow LEDs didn't  fit. Waiting on some nice right-angle SMT LEDs from tvsat.com.pl.  HSMC-C120 LED  

 

 

 

[+FarmerPotato]

Board all populated. Real tests begin. 
 

I had a faded, ceramic 9901 on my desk when I reached for a 99105. They look pretty much the same. But the 9901 feels very different: HOT!  With no clock activity detected, I was checking pins, then "Hey, how was this chip made in 1978?"
 

Weird, the real 99105 had no CLKOUT either. I replaced the crystal and clocks looked great for about ten seconds. Then the oscillator stopped. 

The ROMEN signal was not asserting, so the 99105 was seeing nothing on the bus. 
 

Might it be possible for the 99105 to "lock up" when its A/D bus is floating?  But even the oscillator stopped. It was a known good chip. 
 

[Jimhearne]

I'd be surprised if the 99105 can lock up enough to stop the CLKOUT.

I don't even think RESET stops CLKOUT 

I'd look back further towards the oscillator.

I like using the 4 pin oscillator modules, if you fit an IC socket then really easy to change them for different frequencies for testing and overclocking etc. 

 

[RickyDean]

@FarmerPotato, this is a good idea, I'd like to plant this in my Rave motherboard with my Z80 card and my TI. Three computers in one! 

Edited November 8, 2023 by RickyDean
extraneous information delete.

[+FarmerPotato]

1 hour ago, Jimhearne said:

I'd be surprised if the 99105 can lock up enough to stop the CLKOUT.

I don't even think RESET stops CLKOUT 

 

No, RESET doesn't stop CLKOUT.  
 

The oscillator does get stuck, XTAL1 is high, XTAL2/CLKIN is low. I expect it to reach a solid Vpp within 100 cycles. Theorizing what happens in NMOS if there   are a bunch of floating inputs elsewhere. 
 

The "Duh" answer is the connection is broken, but I measure <0.3 ohms and <20 nF , using a cheap multimeter.
 

I saw this 99105 chip test good on a breadboard. Can try an external oscillator instead. 
 

Pull-ups are on NMI, RESET, READY, HOLD, etc.  Not INTREQ but 9901 is holding that high.