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

[+9640News]

47 minutes ago, mizapf said:

The Geneve video wait states almost drove me crazy ... I just could not find a logical implementation to get the exact behaviour, so I finally gave up for a time, and declared the special cases as rare, with the risk that the MAME emulation shows some deviations in runtime. See https://www.ninerpedia.org/wiki/Geneve_video_wait_states .

I don't know if this helps any, but back in the early 90's, Don O'Neil came out with a chip upgrade that changed the video wait states.  I tested the chip on the Geneve I had at the time that was a full GenMod MEMEX system.  That first modification had reduced the wait states down to a number that was too low and was apparent when running code in 0 wait state Geneve memory.  Don then changed things to be one cycle higher, and it then code doing video writes had no issues.

 

I believe Jeff White and maybe @dhe may be aware of some of those details.

 

 

[+FarmerPotato]

@9640News OK, so assuming at least one wait state,

 

I wonder if the 9995 and onboard 9938 might get more out of their 8-bit bus than the 99105 and 9958.  
 

MOVB *R1+,@VDPWD

 

Just a guess but:

 

99105 does:

IAQ

ALU

WR read

ALU

WR write 

SOP read (might be GM?)

IOP

IAQ

DOP read (word)

DOP write (MSB changed)

1 wait state for external bus 

 

Sum 11

at 6 MHz= 1.833 microseconds

at 3 MHz = 3.66 us

 

 

 

 

9995 and 9938 (bus cycles named for 99105)

IAQ 

ALU

WR read R1

WR read R1

ALU

WR write R1+1

WR write

SOP (*R1)

IOP

DOP (1 byte to VDPWD)

1 wait state for VDP

 

Sum: 11

at 3 MHz = 3.66 microseconds   (Unless I'm forgetting a 2X factor on the 9995 pipeline.) (Old 9900 would take double the cycles.) 

 

 

So 3 MHz is a draw. 16 bit bus requires one extra read-before-write, but 9995 8-bit bus requires 2 extra cycles to read/write 16 bits of R1. But 6 MHz will win. 
 

One cycle could be saved by 99105 MOV because it's smart and does not read before write. 9900 is stuck with MOV and MOVB both having read-before-write. 
 

But all software uses MOVB to VDP, so, oh well. 
 

One complicated idea I have is to make the Recognizer detect MOV vs MOVB, and signal an 8 or 16 bit write to external bus/VDP. It's already designed to detect read-before-write to VDP and suppress it. If the VDP card had a 2 byte buffer onboard, that might yield double the bandwidth, or overrun the 9958 by a lot...

 

 

 

 

[+FarmerPotato]

I've been working on the PCB layout a lot.  

 

Since @matthew180 talked about how a schematic shows structure and flow of the machine, I've taken a look at what mine are saying.

 

I have lots of chips with only the netlist name assigned to each pin.  Most are global symbols.  My organization is to group related things together on 

sheets.

 

So I took one sheet of Geneve 2020, the CRU peripherals, and re-drew it with a left-to-right flow, with more local symbols (labels, in KiCad.)

 

 

EDIT new schematic.  Use 74F377 to latch interrupts on rising CLK.

Edited April 15, 2023 by FarmerPotato
There is a new schematic

[Jimhearne]

Looks good to me.

I think on a complex board it's inevitable that you will have chips with just net names on the pins.

Even if you used busses it still gets messy and as long as the net names are meaningful it's not hard to follow.

 

The only thing that would annoy me are there are a few net names over tracks.

And I'm used to VCC and Ground symbols rather than just net names for them but that doesn't really matter.

 

Jim

 

[+FarmerPotato]

"December" Copper layers.  This is my 3rd routing attempt, starting over clean from scratch. 

 

Still 99 wires left to route.  External bus has bugs. Probably need to rip up and add another PLD. (Yikes.)

 

Lessons learned from routing:

 

Don't postpone the routing of any address pins.

LEAVE MORE OPEN SPACE.  I always fall into the trap of cramming in components. 

Make sure chips are on the grid before routing.

Don't put '259 and '251 chips side-by-side horizontally or too close together. The 8 out/8 in do not match up.  Vertical is a little better. 

Keep looking for a new way to place a quad PLD, when it needs 12 address pins all around the sides. 

 

Digital:

Interrupt latch must be edge triggered to get valid bus data on falling CLKOUT.  Replace '373 type with '377 (Invert CLKOUT.)

 

 

Some design goals NOT in the "December" board:

 

No hardware single-step debugger

Memory mapped ports in 8000 or F100 map to just one external card, say VDP (then no sound, speech, GROM)

No Bus Arbitration

Lacking back panel on card

No Keyboard or mouse, only 9902

 

Features squeezed in at the last minute:

 

8 bus interrupts, assigned priorities by software.

Separate PAD per each GPL and MDOS process.

Mapper supports full 9640 emulation for pages.

 

 

 

December-pcb1.pdf

 

December-pcb2.pdf

[+9640News]

@FarmerPotato Going to ask a question.  Is the 99105 chip readily available?  Asking as I would hate to see you use a chip with a very small inventory on the market limiting any production opportunities.

 

 

[+Ksarul]

105s show up pretty regularly (and sometimes even in quantity). I have about a dozen of them set aside, IIRC. If he was targeting a 110, supply would definitely be an issue.

[+FarmerPotato]

20 hours ago, 9640News said:

@FarmerPotato Going to ask a question.  Is the 99105 chip readily available?  Asking as I would hate to see you use a chip with a very small inventory on the market limiting any production opportunities.

 

 

Hi @9640News,  I am concerned about the supply too.  I was first encouraged when I found I could get them for $33 from a number of places.  

 

I got 3 at $33 from qsourceco_6 on eBay, but they're now asking $68.  polida2008 is still $33.

 

So I'm a little worried about the price.  Other than the TI and Yamaha chips, the other parts are still being made, but cost more and have long delays.

 

 

 

Some critical parts:

Xilinx XC9572XL-tq64 or 44

Lattice 22V10C or 22LV10C

74 series logic ...surprise  shortages of some SO or SOIC packages.

 

So there are a number of chips that might become a risk.   I'm constantly weighing availability, cost, and utility. 

 

My stock is about 7 99105s (some donated, thanks!).

 

 

[+dhe]

Do you have a way of testing the 99105 and Yamaha chips?

[+FarmerPotato]

On 4/17/2023 at 4:34 PM, dhe said:

Do you have a way of testing the 99105 and Yamaha chips?

Just running them in hardware!

 

I tested all the 99105s after I feared I had fried my first one. (It was OK.)

Oh, 99105s: I wrote software tests to verify RAM, bank switching, all the interrupt exceptions, and external Macrostore for floating point. All that will live on as a BIOS ROM self-test. 

 

9958s: I dont know yet if they work!

I expect I'll just be building VDP cards and see if they pass a test battery.  
 

So, my answer is: I test by plugging the chip into my prototype, then  I run software tests, then look at the scope! 

--

 

My prototype 9958 VDP passed memory tests with the the 4464s.  I checked out the RGB video signals on the scope (sync and levels of 8 colors.)  I checked the output after going through  the CXA1645 RGB amp/encoder (from Yamaha, common from PlayStation 1) Then I gave up...

 

Burned much time trying to get the RGB to show up on the Multisync flat panel that Amiga owners have used successfully.  
 

Did not take the next easy steps: test the SCART interface. 

Burned still more time with FPGA writing a 9918 clone and prototyping far-off video ideas.  Went down the TMS34020 and TIGA tunnel.  
 

I'd love to get back to video. Right this moment I'm workin to ensure the December PCB  will be able to  access external VDP card. 

Edited April 19, 2023 by FarmerPotato

[+FarmerPotato]

Weird: I implemented a hardware bootstrap that uses ROM only. 

Until a RUN mode bit is set, all addresses point into 64K ROM. Which would otherwise be at page F0. Requiring the mapper to point at that page. 
 

 The RESET vector workspace is in ROM with pre-loaded registers, like R12=>1340. CRU instructions all use ROM values to  set up the 9902 serial port, with an unrolled loop to print  a string. . Then it sets up the memory mapper using CRU, with page F0 ROM mapped at 0000. Finally it sets the RUN flag, and the ROM code continues running, oblivious that a bank switch  just happened! And it has RAM now. 

 

 

Edited April 19, 2023 by FarmerPotato

[+FarmerPotato]

On 4/16/2023 at 4:20 PM, Ksarul said:

105s show up pretty regularly (and sometimes even in quantity). I have about a dozen of them set aside, IIRC. If he was targeting a 110, supply would definitely be an issue.

The 110 was right out from the start, in fact it was finding the 99105 that jump-started my work.  Also, @pnr 's dump of the 99110 macrostore into external ROM will make the 99105 very close. I've tested the floating point instructions in external macrostore.
 

I unified Macrostore and my BIOS  into one memory space.  (Logically they can be separate, but I want to flash fewer chips!)  After startup, copying ROM to RAM makes it possible to modify Macrostore, or add to it. One day there might be a separate mapper for 64K Macrostore.  

 

So who needs the 110.

 

Except for the LDS and LDD instructions--those are 99110, with a little hardware support.  LDS and LDD let you bridge between two memory maps. 

 

It's possible that some or all 105s conceal working LDS/LDD bit flag registers in the CPU. With  the 110's macrostore ROM, the 105 might be equivalent to a 110.

 

If LDS and LDD don't work, I will implement my own version of the 110's bit flags in the PLD. It already has the inputs which it will need to do that. Oh, and that might be faster than the 110 version?

Edited April 19, 2023 by FarmerPotato

[+FarmerPotato]

Almost ready!

 

[+dhe]

Is the board powered from the MateNLok or from the bus?

 

What do you estimate the power draw to be?

[+FarmerPotato]

Both!  So I can work on it on the bench.  It has a 3.3V regulator on board to power a peripheral, the PMOD SD reader.  Serial port adapter is powered by its own host. 

 

The bus supplies -12, +3.3, +5, +12.  The CPU only uses +5V.  My wire-wrap is consuming 1.2 amp. (so 6 watt).  This one has newer memory, which might actually consume less. 

 

The power board accepts an ATX power supply, 24-pin.  I'm using a PicoPSU 80 watt.  That has the 24-pin ATX, plus one  Mate-n-Lok and one SATA power connector, which can go to the backplane, or just a CPU board.

 

Also almost ready: 4 slot backplane.  I'd make it 8 but this saves $ on fabrication.  Pricier 4-layer board, power and ground planes, because I despair of snaking three traces on two layers. (The cards are 3x32 pins.)

[+FarmerPotato]

A couple details on the backplane:

 

 

• Each card could use a chip to compare its assigned address to the current address on the bus.  Instead I put one chip on the backplane, so that each card gets its SLOT* signal when its address comes up.

 

• Instead of  LEDs  on cards, the backplane provides two per slot.  On the outward-facing side of the backplane. Which is facing the user.

 

• The first LED is P-Box Amber, for card presence/activity.  The card activates an LED by simply grounding it (backplane resistor = correct current), or through an LS07 (open collector), driven by CARDSEL or onboard activity.  What color should the other LED get? Red? I dislike super-bright LEDs. 

 

• The backplane implements Texas Instruments' NuBus, with some modifications.  The bus cycle CLK is driven by this CPU at 6 MHz (NuBus had a common 10 MHz clock).  Fair arbitration is not currently implemented.  I did part of it, on the CPU, which I can test.  TI said the fair arbitration goes into 2 PAL16R8 and 2 74F chips.  (I'm using modern 74ABT parts where fast is needed.)  You only need it if there are multiple CPUs, or a disk controller that does DMA.

 

 

[+dhe]

Maybe Stuart Conner could port over his Cortex Basic to run on this board - so there would be software to test on - before going full GeneveOS?

[+TheBF]

Forth is handier for debugging new iron.  

Should be able to get something to run over the serial port.

[+FarmerPotato]

12 hours ago, dhe said:

Maybe Stuart Conner could port over his Cortex Basic to run on this board - so there would be software to test on - before going full GeneveOS?

I would love to see that.  First thing is to get this built!

 

[+FarmerPotato]

12 hours ago, TheBF said:

Forth is handier for debugging new iron.  

Should be able to get something to run over the serial port.

That is correct.  Forth is best for incrementally bringing up new hardware.  Build on each success by writing higher-level words in place. Plus, some non-volatile RAM to store it in!

 

After RSBUG (a serial version of the TI-99/4A debugger) I need Forth to do the testing.  I would really like  @TheBF's Forth genius on-board (literally).

 

I always planned that Forth would be the language in which the BIOS and DSRs are written.  (Idea from Open Firmware, but using actual Forth.)  

 

Also, plan that you could customize your start-up with some lines of Forth, stored in the non-volatile RAM.  Like whether to open just a Forth prompt, print a menu, or launch GPL or GeneveOS or whatever! Or read a key and launch based on that!

 

 

 

[+FarmerPotato]

Two weeks after finishing the routing of December PCB: I'm still tweaking it. Have not done the simulation to be certain that external bus logic is correct and gets to a VDP card. If I've overlooked a signal that needs to go into the PLD, I want to know before I send off the PCB to be made. 
 

I checked for chip shortages. Serious problems getting '540s and '640s, which are the inverting bus drivers. Needed on each and every card.
 

The really fast versions are the SN74ABT540 and 640. I looked for other parts in inverting bus drivers with the same pinout. It looks like AHCT540 will be ok.
 

I found that there are no narrow '540 chips available, even fewer of all types of Wide than when I last checked.  I had assumed the narrow footprint, when I crammed everything into the bus connector end of the board. 
 

But having the routing 100% means than I can squeeze out any empty space remaining around the bus drivers. I had routed 56 lines (25 address and 16 data, 8 interrupts) across a gap of 22 mm.  Drag and Squish to the left... much cleanup.. got 3-5 mm more out of it. Now footprints are wide SOIC-20.

 

 

 

 

 

 

CPU needs the faster '540s because the LS612 takes 25 ns to get around to the complete address, abd there's in all less than   80 ns after which  external bus address must be valid. Screwing that up in the last PCB (driver OE did nothing  in the first 40 ns) meant that memory would not work at 6 MHz so I've been operating the prototype at 3 MHz. 

So it looks like the 74AHCT chips will do. They have switching times around 10-20 ns.

Although 74ABT are killer at 3-5 ns.
ALS are too slow - 20-40 ns.

HCT or LS are right out, (25-50 ns) and F doesn't have the 540 or 640. I also searched for ACT and BCT but they are rare or pricey $2-3 each. I consider the very dense SSOP packaged 16-bit drivers (one less chip!) but I'm sticking to the SO package, my design rule of no pins denser than 1.27 mm spacing (half the familiar 0.1" thru hole.)
 

74AHCT 540 and 640 are 58 cents, 44 cents in qty 100 (I plan to use a lot of them so..) 

 

So I absolutely gotta work out, and simulate, the total time needed for an external address to settle. (onboard is no problem .) 

 

 

 

Peripherals can be a bit slower though. They are 1 wait state. (That is until I go from 6 MHz to 12 MHz on the external bus clock.)

 

 

 

 

[+Ksarul]

Rochester Electronics has both of them in both DIP and Surface Mount--in vast quantities. Minimum buys are a few hundred each though. . .

[+FarmerPotato]

3 hours ago, Ksarul said:

Rochester Electronics has both of them in both DIP and Surface Mount--in vast quantities. Minimum buys are a few hundred each though. . .

Urgh... I think I knew that, a couple months ago, when I put them into the design. 
 

I must have forgotten, while I  track Qty and Price  directly from TI.com. Where they are still listed ACTIVE status.  
 

One of them had a ti.com Limit of qty 10 yesterday... while Rochester has Min Qty 459!

 

0.96 for 74ABT540NS = 262

0.55 for 74ABT540DWR = 459

0.94 for 74ABT640DWR = 267

I use twice as many 540 vs 640, so this is weirdly symmetric. 

 

Rochester just has a $250 minimum purchase, per line item. 

 

[+dhe]

FPO,

  Spent about 6 hours this weekend getting a MAME Geneve and a real GENEVE updated and booting with MDOS 7.4 and all the new Utils.

  Was thinking it would be real nice to have an all new hardware geneve!

[+FarmerPotato]

6 hours ago, dhe said:

FPO,

  Spent about 6 hours this weekend getting a MAME Geneve and a real GENEVE updated and booting with MDOS 7.4 and all the new Utils.

  Was thinking it would be real nice to have an all new hardware geneve!

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.