+FarmerPotato Posted June 23, 2022 Author Share Posted June 23, 2022 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. 6 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted June 25, 2022 Author Share Posted June 25, 2022 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. 4 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted June 25, 2022 Author Share Posted June 25, 2022 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 6 Quote Link to comment Share on other sites More sharing options...
+dhe Posted August 27, 2022 Share Posted August 27, 2022 How many Geneve2020's can I buy for $1,780 dollars? 😃 5 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 29, 2022 Author Share Posted August 29, 2022 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. 1 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted August 29, 2022 Author Share Posted August 29, 2022 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. 4 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted October 10, 2022 Author Share Posted October 10, 2022 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. 11 1 Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 8 Author Share Posted January 8 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.) 7 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.