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

[+FarmerPotato]

Update:

 

I’ve fixed the memory card, mostly. The PLD is not storing page bits. 
 

I greatly expanded MEMTEST to test XOPs, and CPU error codes. 
 

The Macrostore ROM that @pnr got from the 99110 is loaded. It correctly generates the ILLOP interrupt. 

I know that the page registers are stuck at all 1s, so I could rely on a program in the top page  of ROM, and use the top page of RAM. 

Design Decisions 

 

The next PCB build will have the full memory mapper in FPGA. 
 

I’ll consolidate everything so far into one board with 2MiB of  memory. (128K  ROM.) 
 

The external bus will be NuBus.

 

NuBus has completely fair arbitration. Main use for that is disk I/O doing DMA. 
 

The bus is 32 bits wide. I use 28 address bits for 256MiB. The main memory of 32 MiB will be on NuBus.
 

The memory mapper has a reach of 256MiB, using 16 bit page registers. (User programs can only see the lower 8 bits, for a reach of 1 or 2MiB.)
 

Each of 8 card slots gets a dedicated 1MB of address space for its DSR ROM and any port interfaces.  (CRU is unified into the memory space.)

 

DSR ROMs provide plug-n-play  capability through a system much like Open Firmware. All DSRs are written in Forth. 

Those are the big items.

 

I will spend a little time on the PLD bug, but move on to some actual programs. Or hook up the SD card. 

 

 

 

[+FarmerPotato]

Behavior of ST ERR

 

P. 28 of the 99000 data book describes the “error status register”. (I’m calling this ERR ST.) 

I verified the table on page 28. 

PRIVOP >4000

ILLOP >2000

AF >0010           coincidentally, the same bit used in the ST register.

 

SBZ worked to reset bits, using the addresses in the table.   But the text below it is full of address typos.

I also tried the RSET instruction and it definitely clears ST ERR. (Also RSET requires supervisor mode.) 

 

The bit values I observe in ERR ST:
An INT2 handler must clear the AF condition in ST ERR bit and also ST4 (AF occurred) —else the interrupt will repeat after RTWP (or any LIMI 2). Or you can disable AFIE.
 

Macrostore Surprise

 

my ILLOP test was to execute:

 

DATA >0C0C    undefined, MID

 

Which jumps to Macrostore!  It is the Macrostore program that gets a crack at the opcode.

Without valid Macrostore ROM, I see bad stuff happen (random, but usually infinite loop.)

 

 if the Macrostore program (of the 99110) doesn’t want the opcode, (ie it’s not floating point or some other extension) THEN the program sets ILLOP and returns. Then INT2 occurs. 

Without Macrostore, there’s no ILLOP interrupt!

 

So.. I have my CPU set to External Macrostore (conveniently mapped to my ROM, not a separate address space.)  It was full of garbage test patterns — so lockup. 
 

Cured: I loaded @pnr’s excellent dump of the 99110 ROM. On the first try, ILLOP worked perfectly. (and now I can try all the 99110 instructions!)

 

At last, I’ve got INT2 printing messages for all the cases, and clearing them. 

 

[+FarmerPotato]

Test output now:

 

   ,_,
  (O,O)
  (   )
  -"-"---dwb-
  Geneve 2020
  -----------

Memtest
0C00 3FFE
4000 7FFE X
8100 FFFE
Fail

Bank test ROM >4000 RAM >C000

REG! REG@ RAM@ ROM@
1000 F700 F000 FFFF X
2000 F700 F000 FFFF X
3000 F700 F000 FFFF X
4000 F700 F000 FFFF X
5000 F700 F000 FFFF X
6000 F700 F000 FFFF X
7000 F700 F000 FFFF X
8000 F700 F000 FFFF X
9000 F700 F000 FFFF X
A000 F700 F000 FFFF X
B000 F700 F000 FFFF X
C000 F700 F000 FFFF X
D000 F700 F000 FFFF X
E000 F700 F000 FFFF X
F000 F700 F000 FFFF X
Fail

XOP test: 1234  XOP0 Pass

NMI test: NMI entry. Pass

MID test
INT2: WP 8020 ERR 2000 R13 8000 R14 01A8 R15 D002
Illegal instruction
01A6 0C0C
RSET: WP 8020 ERR 0000 R13 8000 R14 01A8 R15 D002
Pass

AF test
INT2: WP 8020 ERR 0010 R13 8000 R14 024C R15 8822
Arithmetic fault
LDCR: WP 8020 ERR 0000 R13 8000 R14 024C R15 8022
RSET: WP 8020 ERR 0000 R13 8000 R14 024C R15 8022
Pass

PRIVOP test
INT2: WP 8020 ERR 4000 R13 8000 R14 026A R15 D102
PRIVOP:
0268 03A0
LDCR: WP 8020 ERR 0000 R13 8000 R14 026A R15 D002
RSET: WP 8020 ERR 0000 R13 8000 R14 026A R15 D002
Pass

Macrorom floating point test: 7000.0 * 31416.0 / 10000.0
55E7 
Pass

Blink test forever

 

[+dhe]

How many Geneve2020's can I buy for $1,780 dollars? 😃

 

 

 

[+FarmerPotato]

I cleaned up my work area yesterday. I’ve been traveling since June and it was in disarray. 

 

My spiral does record all the hack-y soldering that I did to the memory card PLD on Jun 26. Thank goodness for that.

 

I got in some diagnosing. 

 

22V10 PLD still faulty. No bank switching registers take values. The 0 and 1 writes are definitely clocking the pins correctly, but reads are always 1.

 

Meanwhile, the real ‘259 chip register has always worked  just fine.    It controls the LEDs, and CTS pin for serial. 

 

This PLD has been a massive waste of time, though I learned a lot lot lot while trying to use it. In the memory card, it replaces a ‘259 register and 3 logic chips.

 

 I should just drop that PLD, and cram more chips in. 

 

 

I suspect the XGecu T56 may be at fault. 

 

My PLD design  is thoroughly covered by my test vectors in WinCUPL. With the TL866*, in IC Test, it passed my test sequences, using the real chip.  But it won’t pass in the T56.   The combinatorial logic works, but none of the register bit writes. 

 

I might buy another new TL866 just for this reason. 

 

T56 still works fine for Flash EEPROM. 

 

Maybe XGecu broke the 22V10, when they gave T56 support for the ATF750 PLD. (which I’d upgrade to if I trusted it.)

 

There’s an idea! recompile for ATF750, stick my 24-pin DIP ATF750 in the T56, run the test vectors. It’s pin-compatible, but has twice the buried logic. 

 

Alas, my PCB takes the PLCC chip. And ATF750 in PLCC is out of stock. 

[+FarmerPotato]

On 8/27/2022 at 5:23 PM, dhe said:

How many Geneve2020's can I buy for $1,780 dollars? 😃

 

 

 

I would really like to know, too! Zero? Three?
 

I’m still targeting $500 max. 

[+FarmerPotato]

Magellan as a CAD tool.

 

I needed something to jumpstart my thinking about the circuit board layout. 

 

Made a change using the "clone" tool:

 

 

 

Making the changes in KiCad destroys my routing so far. Oh well, it must be done. 

 

 

 

This revision 'Swan' is where I cut the creeping featurism down a level.

 

It is buildable, with no FPGA or packages finer than 1.27".

 

This board is a all-in-one computer with a serial port. There is 128K ROM on board, and 256K RAM. I did not want to use the 1.27mm pitch SOJ RAM yet, which would give half a megabyte per footprint, so 1MiB on board. 

 

It uses a LS612 memory mapper, so it is definitely not able to pack the 8-bit page register two per word.  So no MDOS compatibility yet. Still, there are 8 page registers at F100 (one word each) .  The two PLDs break out many other signals for Geneve 9640 and GPL memory-mapped IO and external bus access.  The ROM responds at page F0, RAM starts at page 0, and that weird page number routes to an external card for Speech etc.   I will be testing all that. 

 

My goal is to make a big step forward, not finish everything at once. 

 

Nonetheless, I have the option to plug an FPGA/memory mapper board into the LS612 socket!  With an XC9572XL on that, I can reach full 9640 memory-map compatibility, without having to make a whole new board. 

 

This board has the NuBus interface to a backplane.  A VDP card would go onto the backplane.  With the LS612, it has 25 bit addressing. (32 MiB). The plan is for 28 bits (16+12) in a 2-level page management unit.  

 

The first 1/8th (4 MiB) of physical address space is on-board. Externally, 16 MiB is dedicated to specific card slots, and there is uncommmited 12 MiB 
for more RAM.
 

 

[+FarmerPotato]

I got the bugs out of the old memory mapper.

 

Situation: the simple memory mapper was 3 bits for ROM, 4 bits for RAM, implemented as a CRU-addressable register in the 22V10.  Nothing I did would change these bits! They read back as 1s. 

 

Short answer: During a CRU cycle, a '245 driver was not making a proper '0' bit at the end of a really long trace. In fact, its output was disabled during a CRU cycle! 

 

The least significant data bit, aka DOUT, aka CRUOUT, is driven onto the backplane by an ALS245 (directional) on the CPU. The memory card also buffers it on-board with an ALS245. (I use a lot of these chips.) From there, D0 passes by a static RAM and a flash ROM, then the 22V10. But, oops, the output of the '245 is only enabled during a memory cycle. 

 

I jumpered the backplane D0 onto the D0 pin of the 22V10. Problem solved.

 

This is the bug that devoured progress.  On this card that I designed in 2020. It's all so obvious now.  

 

So now I feel fine in making the next card's memory mapper using the 22V10. (Aside from distributors not having any.)  This exact buffering situation doesn't appear in the next  generation (and it wasn't on my wire-wrap build.)

 

Onward...

 

(Aside: in the next gen, the little 22V10's job is to combine two memory map register reads or writes into one word, the way Geneve 9640 accesses them.)