EEC-IV and EEC-V Hardware Notes/talk

[jsa]

Ok, so a post capture calculation for the bank. Are the bank select lines holding state while doing register and ram addressed ops?

[DWS]

I'd say it depends on the generation and what ram it's using. Of my understanding EEC-V can have more than one bank of ram. If there's not a bank select switch before access, it won't change the lines from what I've seen so far.

There's already a ram example in the first example, here's the SAD output to visualize from the bin file. I have two dumps of this code, so based on the memory address, this might be the 2nd dump I did later on, I'd have to check for a difference between them.

Code: Select all

2060: bc,40               word   40bc

2062: bc,40,bc,40,bc,40,bc,40,bc,40,bc,40,bc,40,bc,40  ???  
2072: bc,40,bc,40,bc,40,bc,40,bc,40,bc,40,bc,40,bc,40  ???  

setup: (before the dump section)
20d3: a1,60,20,30         ldw   R30,2060         R30 = 2060;
20d7: a1,00,0a,32         ldw   R32,a00          R32 = I_HSO_0;
20db: b1,e7,36            ldb   R36,e7           R36 = e7;

(op codes matching the capture)
20de: 11,05               clrb  R5               WDG_Timer = 0;
20e0: a2,31,34            ldw   R34,[R30++]      R34 = [R30++];
20e3: 68,32,34            sb2w  R34,R32          R34 -= R32;
20e6: 69,03,00,34         sb2w  R34,3            R34 -= 3;
20ea: c6,33,36            stb   R36,[R32++]      [R32++] = R36;
20ed: c6,33,34            stb   R34,[R32++]      [R32++] = R34;
20f0: c6,33,35            stb   R35,[R32++]      [R32++] = R35;
20f3: 89,78,0a,32         cmpw  R32,a78          
20f7: de,e5               jlt   20de             if (R32 < a78) goto 20de;

Here's an interesting point where it jumps to running code from ram.

Code: Select all

266c: b1,88,11            ldb   R11,88           BANK_Select = 88;
266f: 11,4b               clrb  R4b              R4b = 0;
2671: 11,4c               clrb  R4c              R4c = 0;
2673: a1,ed,02,30         ldw   R30,2ed          R30 = 2ed;
2677: a1,cb,02,32         ldw   R32,2cb          R32 = 2cb;
267b: fa                  di                     interrupts OFF;
267c: c9,00,0b            push  b00              push(b00);
267f: 10,02               rombk 2
2681: f0                  ret                    return;

Code: Select all

5.002876860	SPC_ADD	8266c	
5.002877240	INST	8266c	b1 88 11
5.002877740	INST	8266f	11 4b
5.002878240	INST	82671	11 4c
5.002878740	INST	82673	a1 ed 02 30
5.002879360	INST	82677	a1 cb 02 32
5.002879990	INST	8267b	fa
5.002880490	INST	8267c	c9 00
5.002880860	INST	8267e	0b
5.002881490	INST	8267f	10 02 f0
5.002883110	SPC_ADD	00b00	
5.002883480	INST	00b00	c3 01 84 0f 30

after that point, it loads instructions from bank 0, but writes to addresses in bank 8, so I guess that's how the bank "88" works like.

[jsa]

R11 is covered in the manuals. Low nibble is the data bank and the high nibble is the stack bank.

Yes, interesting alright. Setting rombank 2 but you've recorded as bank 0, I presume because you are only monitoring 2 bank select lines?

Did you enable the Execute Enable Register somewhere else to allow code execution from RAM or has it gone off into the weeds?

[DWS]

That's not my code lol, it's a capture of some stock code. Capture is based on MB0-7, BS0 and BS3, DI, TI, STB.

Here's where EER is set. This is the EPIC version of the 8065 if I remember correctly, can get exact part numbers to document the EER reg.

Code: Select all

4.621340410	INST	820f9	b1 aa 30
4.621340910	INST	820fc	c7 01 1f 0f 30
4.621341780	MEM_WRITE	80f1f	aa

It uses F00-F02 area a lot. I haven't done anything with CART/EBC, but addresses are lining up pretty well to the 81C65/81C66 mapping for mask D. Quick peek at CART vs EBC, it looks like it's EBC mapped in the F00 range.

[jsa]

Ok, so BS1 could be high but the capture is blind to it.

Yeah, what's the catchcode, strategy, hardware code and part number for that BIN/box, please?

I'd expect CART to be surprise free based on code I've seen. Yep D mask should be F00.

[DWS]

Yea I didn't hook up BS1 or BS2. It's possible to, I can support 16 channels, so 8 bus, 3 control, and 4 bank would use 15 of 16 up and I'd have to update the script that looks at the signals to take into account the other 2 bank select switches. I suspect a capture of some test code would be interesting to you to monitor bank select effects under some conditions?

I just received my ribbon cables with the J3 connector on them and they appear to line up well, so I'll have to decide the best way to interface with things moving forward for dev work. Maybe a simple breakout board/pass through, like J3 -> J3 that has a pin header for the LA and another J3 for any chip/adapter testing, That might be a bit too long though to be reliable. I'll figure something out though.


On a side note, since I have access to these tools and such, I've started a side quest.... 8061/8065 emulator. Not sure if it will ever show up in the public space, but I know disassembly wise having the code be effectively processed as if it's really running it would help catch all logic paths and tricks used in code even if timing and accuracy isn't quite 100% (I'm not simulating at the cpu clock/bus level, that's all estimated). Never took on a task like this, but so far it hasn't been too bad. Defining each op code is the bulk of the work so far. I have support in the design for support chips like the ram chip and such. Once I get the bulk of the instructions covered, I think a test program will need to be created to test each op code in real life vs simulated to validate all expected effects line up. This is getting wrote in C++, so should be fun to see what real time performance looks like. Primary thing I'm looking for is tracking memory/ram usage and code path/calibration settings etc. Real time input processing might not be quite real time, but it should work at the IO pin level unless I build out each hwid mapping/special features, but trying to keep it a bit simpler for now lol.

Of course I'm starting with 8061 and the most basic of setups for the initial testing.

[jsa]

I'm interested in what the BS lines are doing on you previous example.

Code: Select all

267c: c9,00,0b            push  b00              push(b00);
267f: 10,02               rombk 2
2681: f0                  ret                    return;

I'm also interested in the catchcode, strategy, hardware code and part number for that BIN/box, please?

Building an 8061/5 emulator is quite a project.

I run a flexi-pcb between the J3 port and QH. It's over 3/4 the length of the EEC box.

[DWS]

I would assume setting bank select to 02 would be bit wise 0010, so BS1 high while BS0 and BS3 low. I haven't physically followed the pin, but at this point I'd guess it's involved with the ram chip, even if it's internal.

I'd have to look at which computer it was, I've been jumping between a lot of stuff lately. I'm sure other computers do something similar. It's out in the shop, so pretty far from the desktop computer I'm posting on, so keep forgetting to check the part number info on it, it's nothing special though.

Yea, the emulator is like 7000 lines of code already. Defining op codes takes up most of it. It's pretty neat seeing the hex be disassembled as it's being ran (current design). I doubt it would get to SAD levels of disassembly, like C references, but hex -> asm shouldn't be too bad. So far cpu, ram, rom memory views work and the main program log (later gonna be the disassembled version of the rom), also expose some internal cpu registers in the window to make sure everything is making sense. As long as high level items work 100% accurately, any strange code designs should operate correctly for following code logic paths. Will see how well things work out though lol.

The ribbon cable I have is 20cm, I think one probably is ok, but two probably would be pushing it too much. Probably makes the most sense of J3 - ribbon - J3 card, pinheader, and J3 board edge, then have the J3 device attached right to the adapter board, or my arduino/fpga via pinheaders, etc.

[jsa]

I expect BS1 to be high too. Special or not, it should be checked out to see if it provides any challenges for SAD's ongoing development. We've not come across any bins using banks other than 0 1 8 9 before, so when you can, share the details, it'll be appreciated.

7000 lines, that quite a lot already.

Working J3 cable length limit might be higher than expected. I saw a console on ebay years ago, it had a lengthy J3 cable, but it was round though. Cable impedance will matter of course.

[DWS]

I see, once I catch up on some things I'll have to get the LA hooked back up and add the pins I suspect would be BS1/BS2. The J3 pinout calls the 2 bank select pins BS0 and BS3, and the binary mapping of 0, 1, 8, 9 matches exactly what I see the lines do within that context, so that's what I'd expect would happen for BS1 and 2 lines to mach the lower nibble states, never know though lol.

Yea, lot of lines, but will need to be well tested to validate it's accurate. I'm to the point of adding the estimated time metrics to everything for Master I/O Timer and defining a clock speed and such. Most op codes I have defined at least loosely.

The old engineering console I'm pretty sure wasn't used on EEC-V era, so max clock I'd assume is around 18mhz (~6mhz bus speed). I don't normally work with high frequency signals, but I do know keeping wiring as short as possible is ideal. My ribbon cables are just the standard style ones, would be nice to get ones made with the every other wire is a ground type of setup like the 80 wire IDE cables. I guess the standard cables handled something like 66mb/s (6.6mhz?) and were somewhat long. Never really looked into the raw IDE bus design though, probably larger than a 8 bit bus.