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.)
 

[+FarmerPotato]

Progress on "Swan" now  called "December".
 

Many changes and one big problem solved. 

 

I did 65% of the routing. While deep in this concentration, I get many new ideas. 

I've solved the memory mapper problem. 
 

 

 

The problem is that  GeneveOS accesses two 8-bit map registers with one MOV instruction.  The 9995 does this as two MOVB cycles on its 8-bit bus.  The 99105 does one cycle on its 16-bit bus. Also MOVB does read-before-write. Something is needed to split that across two map registers. Also, my map registers are 12 or 16 bits wide. 
 

The solution is to treat map registers just like PAD, but assert a Privilege Violation interrupt immediately. Then the handler can read what changed in PAD and "do it in software."  
 

The 99105 data book  suggests that you use external INT2 for bus faults and privilege violations. Saw this when I was routing external interrupt pins. 

PAD access already goes through a "hole" in whatever page is mapped around it. PAD access goes to "shadow RAM" instead. 
 

It's simple to extend this area to the map register addresses. 

(PAD is the internal 256-byte RAM  of the 9995, which must be emulated for compatibility. In GPL mode PAD is the 8300 block; 8000 is map registers.) 

Details

 

One "Recognizer" PLD is always watching A15:0. (TRON reference.)  It asserts signals  for any special address.  It  recognizes access to map registers, VDP, PAD, chips on CRU, the LREX instruction, and other stuff. Holes are just more PLD equations. 
 

I considered whether the INT2 handler could decode and emulate offending instructions. Complicated!

 

But if the instruction just writes to shadow RAM, the INT2 handler can  copy changes in shadow RAM to the mapper. Easy peasy. Reads from shadow RAM work fine.  Everybody's happy. 
 

What if interrupts are disabled? Could be a bug. 
 

Actually, interrupts are never disabled except in critical BIOS code! 

 

MDOS or GPL are denied access to the interrupt mask. LIMI (Load Interrupt Mask) is a privileged instruction. The BIOS gets a Privilege Violation (INT2 again) and merely caches the requested interrupt mask for that process. All interrupts are handled by BIOS, which can forward them to a process, or queue them for later delivery, after another privilege violation with  LIMI 2 or 4. 

So INT2 is never disabled outside BIOS critical code.

 

(I might allow a mode where GPL can really disable interrupts, just for games. I aim to achieve better 4A hardware abstraction than even Geneve 9640 had.)

 

The mapper-shadow RAM solution comes after a dozen other attempted ideas. Some were  incomplete, some too risky or ambitious.

[+FarmerPotato]

Besides the memory mapper offering compatibility with GeneveOS, other features on the "December" board:

 

* 3x 512K RAM. 

* 2x 128K Flash ROM. 

(Can use 256K chips too.) 

* Pages F0-FF are the first 128K ROM. 
* One serial port for console access/keyboard. (Temporary until PS/2.) 

* Back Connector for SD card reader, interfaced through 9901.

New 4-slot backplane , 96-pin connectors, routed and ready for production along with "December".  
 

An external card will be needed to implement GROM. 
 

VDP and sound are another card. To get this sooner,  my example card will be bare-bones with  a socket for the  F18A. (9958 still coming.)

 

32 "B row" traces of the backplane are available for built-in connectors   like VGA, PS/2 keyboard/mouse, sound jacks. Cards could share one channel for  digital sound (I2S). 
 

So a VDP card can reach either one built-in VGA connector, or provide its own connectors. Audio cards can reach either the built-in connectors or provide their own. 
 

There's a chance that "December" has enough potential for full hardware/software compatibility. 

[+FarmerPotato]

I'm making progress. Pretty picture:

 

 

 

This uses components on both sides of the board.  But it's just 2 layers. 

 

[+InsaneMultitasker]

Love the Tron reference and these periodic updates.  Neat journey you've embarked on.

[SkyPilot]

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

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

 

 

 

 

Total insanity.

[Tornadoboy]

I'm not suggesting it should happen, especially now with this coming out as it'll be 1000x better, but how come nobody has (well to the best of my knowledge) ever done a repro of the original Geneve? Does it have custom chips nobody has figured out or something?

[RickyDean]

5 hours ago, Tornadoboy said:

I'm not suggesting it should happen, especially now with this coming out as it'll be 1000x better, but how come nobody has (well to the best of my knowledge) ever done a repro of the original Geneve? Does it have custom chips nobody has figured out or something?

The gate array was never reproduced or decoded, though there are one or two prototype Geneves, that did not havevthe gate array, they used store bought chips. So maybe that would help a future hobbyist.

[+Ksarul]

BTW, the prototype Geneves may not help as much as you might think. I just looked carefully at a picture of mine. They don't have the Gate Array, but they do have a pair of PAL chips instead. There were also some "interesting" layout errors (the front traces are on the bottom of the board and the back traces are on the top, so they needed an adapter that flipped the pins front to back and vice versa to actually plug it in to the PEB bus).

[+FarmerPotato]

11 hours ago, Ksarul said:

. I just looked carefully at a picture of mine. They don't have the Gate Array, but they do have a pair of PAL chips instead. 

 

Supposing this one is in your infinite collection, can you take a new photo? 
 

So far I've used two 22V10 PLDs to get a good deal of the needed GPL/9640 behavior, but those don't have the bigger stuff like 64 bits of  mapper register, or the AT keyboard controller.
 

(Reference on keyboards: wiki.OSDEV.org is an amazing retro-programming website.) 
 

(22V10s are still produced, which supercede any of the 16R8 kind of PLAs.) 

 

[+FarmerPotato]

16 hours ago, RickyDean said:

The gate array was never reproduced or decoded, though there are one or two prototype Geneves, that did not havevthe gate array, they used store bought chips. So maybe that would help a future hobbyist.

 

My take so far, is that the Geneve hardware is well enough documented to create a compatibility layer.  
 

Documentation exists thanks to@mizapf , for MAME, and all those who wrote comments in GeneveOS @InsaneMultitasker @9640News including those who are no longer around.
 

(The boot sequence code is really interesting!)

 

Remaining details like the PAL with wait state settings... uh.. I do not have a great solution for wait state and speed matching. 

My process was to go through the documented features, one by one, to  create the appearance of a 9640. Still, bringing up standard GeneveOS, in the abstracted machine, is a risky task and a long way off! 
 

At one point, I did my PLDs and other chips (LS612) in Verilog test benches. I've put in enough simulated bus cycles, from the 99105, to see that it works. Also, needed to see if it fits into one or two XC9572s. 
 

Gotta redo that simulation for the December board. (I made so many changes last week!) 
 

Only the video/audio card requires a fancier FPGA.

 

Disclaimer: I don't do hardware for a living! Much has been learn-as-I-go. 

[+mizapf]

We have equations for the PAL; the bad thing is that I cannot get the wait state generation in MAME exactly like the real machine with them. In rare situations, wait states are lost, that is, the MAME emulation is slightly faster. As for the Gate array, its behavior is well enough understood so that I could create an emulation from it.

[+FarmerPotato]

1 hour ago, mizapf said:

I cannot get the wait state generation in MAME exactly like the real machine with them. In rare situations, wait states are lost, that is, the MAME emulation is slightly faster. 

I've almost given up on wait-states in 9640 mode. Doing so would require a table of 9995 cycles minus 99105 cycles for each instruction. I do want to do that for the 9900. Reasoning: we need the ability to run GPL at original speed.
 

So I may have just one speed setting: 99/4A and Full Throttle. 
 

The 99105 helpfully outputs bus status code (BST) for IAQ, IOP, WR, SOP, DOP, GM. So the initial IAQ preps initial  wait states due to the opcode, and the others stand in for whatever addressing mode is used. I have a signal E_PAD that indicates whether a memory access is to PAD (fewer wait states on memory.)

 

[+InsaneMultitasker]

8 minutes ago, FarmerPotato said:

've almost given up on wait-states in 9640 mode.

I only have one cent to offer : pretty much every MDOS program expects to run from fast ram and as 'quickly' as possible, so I'm not sure of any concrete reasons for adding wait states for the OS and native 9640-mode programs.  There are some issues with peripherals in /4A mode (i.e., rompage) but you are already considering 9900 /4a mode timing.

[+FarmerPotato]

19 hours ago, InsaneMultitasker said:

I only have one cent to offer : pretty much every MDOS program expects to run from fast ram and as 'quickly' as possible, so I'm not sure of any concrete reasons for adding wait states for the OS and native 9640-mode programs.  There are some issues with peripherals in /4A mode (i.e., rompage) but you are already considering 9900 /4a mode timing.

Thanks for clearing that up: I will stop worrying about it. 
 

The VDP interrupt is still there at 60 Hz for GeneveOS to use as a task slicer.
 

Games in GPL that poll for VDP interrupt with TB 2 ... have sort of figured that out..

 

BIOS always gets the interrupt first, then it simulates what would happen. Lets GPL run even if it has masked interrupts-- In case GPL code was polling TB 2. 

[+InsaneMultitasker]

19 minutes ago, FarmerPotato said:

The VDP interrupt is still there at 60 Hz for GeneveOS to use as a task slicer.

Thinking about my earlier comment, I was only considering the ram wait states.  For example, there are VDP wait states, which are enabled by default at OS startup; some programs require vdp wait states due to how they are written.

[+FarmerPotato]

On 3/31/2023 at 11:13 AM, InsaneMultitasker said:

Thinking about my earlier comment, I was only considering the ram wait states.  For example, there are VDP wait states, which are enabled by default at OS startup; some programs require vdp wait states due to how they are written.

 

If it's just to prevent memory overrun, ok.  The 9958 added its own READY output.  Also, there is a nice MSX hack where they put a 1 byte buffer in front of the 9958. So you may see no wait state necessary.  (Can construct this around a LS374 octal flip-flop and another LS74.) 

 

Also, my external bus access are minimum 2 cycles, according to TI's NuBus.

 

NuBus was designed with multiplexing of address and data on AD31:0.  Cycle 1 is Address, START is asserted. Cycle 2 is Data.  The peripheral asserts ACK in the data cycle if no wait states are needed, or withholds ACK until it is READY.   So, 2 cycles normally.   That's going to be 333 ns per external cycle.  Onboard RAM takes just one cycle or 166ns.*

 

Whereas NuBus had its own 10 MHz clock on the backplane, I'm driving the BUSCLK from the 99105's 6 MHz CLKOUT.  With an external BUSCLK, independent CPUs would have to wait a fraction of a cycle to get in sync.  Everything is synced properly by rising/falling edges of BUSCLK.

 

(Later, when I do bus arbitration, there has to be an additional 0th cycle to reserve the bus.  But NuBus is completely fair and wastes no cycles. That 0th cycle can occur during someone else's Cycle 2, similar to a prefetch.  That doesn't help a lone CPU which is the only bus controller!)

 

Another cycle-saving trick is, on the CPU's write destination operand cycle (DOP), the CPU can ignore wait states. To do this, you need another buffer between the CPU and external bus, much like the MSX trick where VDP buffers up to one write.

 

*(For the 99105,  MOV R1,R2 instruction in onboard RAM totals 3 cycles or 500ns, assuming the instruction is in the CPU pipeline)

SOP (source operand read)             

IAQ  (prefetch next instruction)

DOP (destination operand write)  (decode next instruction)

...

 

 

[+mizapf]

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 .