[tvrfan]

...
Yes, as I have noted to TVRfan, treat the manuals with great suspicion they were printed well before production silicon and revisions thereof.
...

I wouldn't go so far as to say "great suspicion", I think it's more like "some details may have changed since", but the principle is right.

also I should have said -
Originally from Ford handbook, it was assumed that only Ra operand had the 'odd address word' mode, as that's what it says with the 'step D' reference, but then a bin turned up which showed it had to be ALL operands. The manuals then appeared (great!!) and they also say Ra in their diagram (as per above), and the text description doesn't clarify (as I remember). Anyway, we proved it's actually ALL operands in direct mode. So this is all it takes for a little suspicion and doubt to creep in ...

[jsa]

I wouldn't go so far as to say "great suspicion", I think it's more like "some details may have changed since", but the principle is right.
...
also I should have said -
Originally from Ford handbook, it was assumed that only Ra operand had the 'odd address word' mode, as that's what it says with the 'step D' reference,

I am at great suspicion because the step D 8065 hardware I tested did not do Ra odd address word mode.

I am greatfull that we have the manuals.

[jsa]

SFR07, SFR0F, SFR11, SFR13, SFR15, SFR17, SFR19, SFR1D, SFR21 and SFR23, what's it to be?? SFR word access or SFR +100??

I am not sure what your question is here. If you are trying to access these odd addressed SFR's you just you a use a byte read or write (where writes are permitted).

?? Is a rhetorical question because the manual states R14 can be accessed by word addressing R15, but so far testing shows it doesn't.
The manual claims some of the odd registers have a different purpose depending on whether they are accessed in a word or as a byte. So no you could not just use a byte in some cases, based on the manuals description.

Stick that in your pipe and smoke it! Reconcile that with 0x15 is 0x115.

I think this is referring to using a 16 bit address to read or write word sized data and not the direct address mode 8 bit odd address method to read or write word sized data

A 16 bit address mode, do you mean long indexed, for example?
Word long index odd Rb and Rd access +100.

[jsa]

What kicked this off is about the later added (?) feature of accessing direct registers as words with odd addresses being used to change RAM banks, and whether or not this applies for special func registers (addresses < 0x20 ). The Ford handbook, but not the manuals, has a reference to "from Step D" implying this 'odd word' direct mode was added to 8065 sometime later, but manuals imply it's always true.

The tested D step 8065 did not do +100.

This also leads to 0x0, 0x100, 0x200, 0x300 can also be regarded as 'special', so does 0x1 work as 0x100 ?? Not that anyone would bother I guess, but still..... I think jsa found a bin that does NOT work this way ?? I'm not sure, but this is why he was asking the question.

Under test, one could not tell if the zero's were accessed by +100 as the result will always be zero.

The P3M box, step D 8065, did not do sf/r+100 under the test.

As to whether 'odd mode' changes in mem-expand, I don't think anyone has even asked THAT question until now ! (but I would assume not)

I had given it thought. Wwhite asserted that on the other forum.

We know mem expander mode supports sf/r+100. The test bins are written for non mem expander mode. OEM VILE code is mem expander mode. The VILE box supported sf/r+100 in non mem expander mode under test.

I have since checked the mem expander mode bit to confirm to wwhite that tests are running in non mem expander mode.

Has anyone got examples of using odd addresses with word mode special func registers ?? I expect not, but it's still a valid question to ask.

Over to anyone with examples.................

I concur.
Run the test bins on that hardware if anyone has an example, please.

[sailorbob]

The manual claims some of the odd registers have a different purpose depending on whether they are accessed in a word or as a byte. So no you could not just use a byte in some cases, based on the manuals description.

You listed a bunch of 8 bit SFR's at odd addresses so I stand by my statement that you access these odd address SFR's by means of a byte read or write (where writes are permitted). Whilst the high byte of a word sized SFR may share the same address use a word read or write (where writes are permitted) at the preceding even address to access the SFR.

Which page(s) is the 'step D' reference on?

[jsa]

You listed a bunch of 8 bit SFR's at odd addresses so I stand by my statement that you access these odd address SFR's by means of a byte read or write (where writes are permitted). Whilst the high byte of a word sized SFR may share the same address use a word read or write (where writes are permitted) at the preceding even address to access the SFR.

On the same page as you with this description. I thought you were saying something else with your previous reply. Thanks for clarifying.

Which page(s) is the 'step D' reference on?

Page F2 of the handbook describes a D-STEP DUCE difference.
Page D2 of the handbook describes the DUCE support IC as Mask D.
The DUCE IC3 inside P3M is an 81C65-D
So I'm talking of an 8065 that works with 81C65-D.
The 8065 markings are;
P8065 9230
76016CCC P
L2305265

For quite some time, we have been talking in the background about how the 8065 may have changed as development progressed, and referring to changes as steppings. Sorry for any confusion.

I don't recall reading anything relevant in either manual.
Probably something there somewhere to be found on a re-read.

[sailorbob]

I suspect the 'step' and 'mask' changes are different things in the DUCE chips. You won't find a DUCE mask A chip used with an 8065 because of the overlap of RAM addresses in the 0x0100 to 0x3FF range.

I doubt the 8065 has changed throughout its life. if there are any discrepancies between how the 8065 operates and the reference manual it is most likely an error in the text.

Regarding the sentence on page 6-14 saying 'Hence, either address *0014 or *0015 can be used in the word reference
to simultaneously access both bytes of the HSO interrupt pending register #2.' if this is incorrect then it's probably a moot point as I'd expect the assembler to at least throw a warning that a word read / write operation is being attempted on an odd address (or correct the address and give a warning).

[tvrfan]

Bob,
my opinion -

I'm open minded on whether 8065 silicon actually changed or not, but remember Ford handbook has this "from Step D" reference, so it's implied that it did.

I'm inclined to agree with you that the manuals are more likely wrong/inconsistent. I noticed a LOT of the 8065 CPU wording appears to be a direct copy from 8061 text (as it should), but it's quite possible that text describes situations that can never occur on 8065 because of extra functionality, and it wasn't cross checked properly. I agree about the compiler too, but I remember seeing a bin where it swapped banks just to get R0, which is a truly STUPID compiler mistake... (BWAK3N2? Um...) So who knows ??

We have bins that don't conform to the the 'layout maps' in the manuals, I'm sure that the short bank/high ram doesn't appear anywhere either (RZAS... and others), so it still indicates some ongoing development.

Only the bins themselves (and H/W) will confirm.

[tvrfan]

I found this in BWAK3N2 (called it 'regbnk' for 'register bank') ..... Why do this ???

Code: Select all

824b0: f4                 regbk 0                
824b1: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824b6: f4                 regbk 0                
824b7: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824bc: f4                 regbk 0                
824bd: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824c2: f4                 regbk 0                
824c3: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824c8: f4                 regbk 0                
824c9: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824ce: f4                 regbk 0                
824cf: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824d4: f4                 regbk 0                
824d5: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824da: f4                 regbk 0                
824db: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824e0: f4                 regbk 0                
824e1: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824e6: f4                 regbk 0                
824e7: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824ec: f4                 regbk 0                
824ed: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824f2: f4                 regbk 0                
824f3: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824f8: f4                 regbk 0                
824f9: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
824fe: f4                 regbk 0                
824ff: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
82504: f4                 regbk 0                
82505: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;
8250a: f4                 regbk 0                

if the answer might be 'because of interrupts' then why not have di and ei .........must be quicker....

[sailorbob]

We have bins that don't conform to the the 'layout maps' in the manuals, I'm sure that the short bank/high ram doesn't appear anywhere either (RZAS... and others), so it still indicates some ongoing development.

I am not entirely sure what you mean by 'short bank' but if you are referring to the direct address mode 8 bit odd address method to read or write word sized data then RZASA definitely uses it; e.g. see line 0x87241 where pwoff is accessed using this method.

The 'high ram' is probably not listed in the reference manuals because they pre-date the introduction of a RAM chip with the 0x1F000 to 0x1FFFF address range.

[tvrfan]

'short bank' - RZAS etc have a bin format with bank 1 only being 0x2000- 0xdfff instead of 0xffff. From disassembler analysis this makes it a 'short bank' as RAM area doesn't appear. This messed up my SAD bank detection code, which assumed a 'full bank' in the file, with or without the first 0x2000 bytes (default 'standard' layout). Latest SAD versions don't assume any bank size and scan whole bin for bank start profiles.

Yep, RZAS uses the 'odd word' mode. I understand why rbnk 0 is required for ORW and bit class operands, but looking again at that STW code sequence makes even less sense to me now, as NOT having the 0xf4 at all must surely give exactly the same result in ALL rambanks ???

Code: Select all

824b0: f4                 regbk 0                
824b1: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;

or have I got that wrong ?
(this may be a bit off topic, but shows that errors do creep in everywhere...)

[sailorbob]

Ah, by 'short bank' you mean 'shortened ROM bank' :) As the conversation was about RAM your phrase confused me.

No idea what the BANK0 of the BANK0, STW ZR,$11F00[ZR] is about but 0x1F00 is related to the use of a Research Console (RCON) and can be found in 8061 code too. Out of curiosity why the 17th bit in the address in your disassembly extract? All the 8065 RAM addresses are in the 0x1nnnn range but the disassemblies don't display the leading 1 for most of the addresses.

[jsa]

I suspect the 'step' and 'mask' changes are different things in the DUCE chips. You won't find a DUCE mask A chip used with an 8065 because of the overlap of RAM addresses in the 0x0100 to 0x3FF range.

As TVRfan noted, add handbook page C14 to the D-step references.
I had concluded that mask and step were equivalent, but maybe not.
My view is the uP and external devices have to be paired so the the respective Program Counters stay in lock step.

No A with 8065, makes sense uP and external devices must understand respective memory ranges.

I doubt the 8065 has changed throughout its life. if there are any discrepancies between how the 8065 operates and the reference manual it is most likely an error in the text.

P3M vs VILE hardware test results indicate that the 8065 did change, well at least in the absence of a clear config reason for the different test results.

Regarding the sentence on page 6-14 saying 'Hence, either address *0014 or *0015 can be used in the word reference
to simultaneously access both bytes of the HSO interrupt pending register #2.' if this is incorrect then it's probably a moot point as I'd expect the assembler to at least throw a warning that a word read / write operation is being attempted on an odd address (or correct the address and give a warning).

That sentence VS odd word addressing is the cause of this whole test process and subsequent discussion. Both being true is diabolical.

I would not expect an assembler issue, as an odd word address is a +100 address. Additionally some DUCE accesses are an odd word. Yeah ok, maybe they did based on memory range.

Word access of *0015 is actually *0115 as born out by the test results.
Scouring bins for SFR14 access via *0015 has proven fruitless therefore that part of the manual appears to be incorrect. However I remain open to proof to the contrary.

[wwhite]

Code: Select all

824b0: f4                 regbk 0                
824b1: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;

or have I got that wrong ?
(this may be a bit off topic, but shows that errors do creep in everywhere...)

I read that as the following:
- ^F4 BANK0, select bank 0 for the following instructions
- ^c3 stw, 01 long index, 00 lowbyte ,1f high byte , reg 00
- bank#0 R^00 -> (^1F00 + R^0) = [0 1f00] = 0

Your disassembly makes me think your storing zero into Bank1 address 0x1f00.
Where I disassemble, and see Bank0 address 0x1f00.
Maybe I am miss-reading your [11ff00].

I always thought that the multiple stw R0,[R0+1f00] as being 'wait states', or 16 more execution states.

[sailorbob]

Speaking on general terms, and not being microprocessor specific, I do not see any problems with a processor allowing both using the direct address mode 8 bit odd address method or a 16 bit odd address to read or write word sized data. To do the latter the processor merely ignores the least significant bit of the 16 bit address; i.e. reading a word of data from 0x0015 would read the data from 0x0014.

[sailorbob]

From a little research it appears that a 'step' is Intel speak for a revision and it's usually on a pre-production or very early production chip.

[wwhite]

So I'm talking of an 8065 that works with 81C65-D.
The 8065 markings are;
P8065 9230
76016CCC P
L2305265

Can you post a picture of the chips and circuit board please?

[tvrfan]

Ah, by 'short bank' you mean 'shortened ROM bank' :) As the conversation was about RAM your phrase confused me.

No idea what the BANK0 of the BANK0, STW ZR,$11F00[ZR] is about but 0x1F00 is related to the use of a Research Console (RCON) and can be found in 8061 code too. Out of curiosity why the 17th bit in the address in your disassembly extract? All the 8065 RAM addresses are in the 0x1nnnn range but the disassemblies don't display the leading 1 for most of the addresses.

Bob, Yep, I should have described that better....'short ROM bank' OK.
Bank 1 in addresses- on the basis that the DATA bank for all multi banks is 1, (as set in R11 = 11; at the 'boot up' sequence, and always reset to 11 after subroutine argument getter code) I added it to SAD after getting user requests to reduce confusion. So SAD keeps track of current data bank as well as code bank. All data accesses > 0x3ff are considered to be in data bank (1 by default). So far, this seems to be correct.

For those of you not quite up with these tricks, if you look at a subroutine which gets arguments (especially one which does it on behalf of a calling subroutine) the code clearly shows how the data bank versus code bank works. I'll post an example to explain.

For that code snippet , I did consider afterwards that it's just possible that the rambank 0 opcode introduces a short delay between writes, which may be a reason, but it still looks to me like it's a compiler thing (as in "0 is always from R0 not R100" etc.).

[jsa]

uP and chipset

IMG_20210428_055956602.jpg (168.77 KiB) Viewed 68715 times

[tvrfan]

Code: Select all

824b0: f4                 regbk 0                
824b1: c3,01,00,1f,00     stw   R0,[R0+1f00]     [11f00] = 0;

or have I got that wrong ?
(this may be a bit off topic, but shows that errors do creep in everywhere...)

I read that as the following:
- ^F4 BANK0, select bank 0 for the following instructions
- ^c3 stw, 01 long index, 00 lowbyte ,1f high byte , reg 00
- bank#0 R^00 -> (^1F00 + R^0) = [0 1f00] = 0

Your disassembly makes me think your storing zero into Bank1 address 0x1f00.
Where I disassemble, and see Bank0 address 0x1f00.
Maybe I am miss-reading your [11ff00].

I always thought that the multiple stw R0,[R0+1f00] as being 'wait states', or 16 more execution states.

Yes could be a time delay/wait state, but again, WHY? as previous post to bob, the bank 0 could be a (small) wait, and those multiple reads would clear out a data queue in a chip or console mapped to 0x(1)1f00.
see above post also for why address represented as 0x11f00 by my SAD disassembler.

[jsa]

P3M box.

20210405_171526_1.jpg (205.37 KiB) Viewed 68713 times

[jsa]

From a little research it appears that a 'step' is Intel speak for a revision and it's usually on a pre-production or very early production chip.

Yeah, CPU bug fixes, energy improvements, performance improvements. Have seen AMD use the term that way as well.

Step D, still an 8065 but revised.

[tvrfan]

Quick code examples for why bank 1 is always data bank, from xdt2.
Near the start

Code: Select all

820b8: fa                 di                     interrupts OFF;
820b9: 11,0b              clrb  Rb               IDDQ_Test = 0;
820bb: b1,11,11           ldb   R11,11           BANK_Select = 11;
820be: 91,10,0a           orb   Ra,10            MEM_Expand = 1;
820c1: 11,0c              clrb  Rc               HSI_Mask = 0;

820bb - R11 sets bank for DATA and STACK, and is set to 1 for both (= 0001,0001)
this code then goes on to initialise a list of RAM addresses and registers

Subroutine argument getter, on behalf of a calling procedure

Code: Select all

82f93: a3,20,02,36        ldw   R36,[R20+2]      R36 = [StackPtr+2];
82f97: a3,20,04,3a        ldw   R3a,[R20+4]      R3a = [StackPtr+4];
82f9b: f2                 pushp                  push(PSW);
82f9c: fa                 di                     interrupts OFF;
82f9d: 18,02,37           shrb  R37,2            R37 >>= 2;
82fa0: b0,37,11           ldb   R11,R37          BANK_Select = R37;
82fa3: b2,3b,36           ldb   R36,[R3a++]      R36 = [R3a++];
82fa6: b2,3b,37           ldb   R37,[R3a++]      R37 = [R3a++];
82fa9: b2,3b,38           ldb   R38,[R3a++]      R38 = [R3a++];
82fac: b2,3b,39           ldb   R39,[R3a++]      R39 = [R3a++];
82faf: b1,11,11           ldb   R11,11           BANK_Select = 11;
82fb2: f3                 popp                   PSW = pop();
82fb3: c3,20,04,3a        stw   R3a,[R20+4]      [StackPtr+4] = R3a;

This code sets the databank to the caller's bank, (from the psw, pushed in the calling procedure), gets 4 bytes and resets data bank.
note that it does NOT restore the state of R11 from its own pushp, confirming that data bank is always 1 (except for special stuff like this 'get')

[Yes, officially there is no actual Databank, Codebank as such. Logically though, there IS, because they DON'T overlap in function. The code itself proves that. R11 has databank, and codebank is hidden, only accessible/amendable indirectly. But it does exist. ]

[ollopa]

The "D" 81C65-D is just address mask option D, isn't it?

address mask options.jpg (126.4 KiB) Viewed 68702 times

I can't find any documentation suggesting that the CPU needs to be paired with or has revisions associated with the RAM/CART/DUCE chip.

Is the VILE EEC using the same 81C65-D / how do its part numbers compare to the P3M?

[jsa]

The "D" 81C65-D is just address mask option D, isn't it?

Maybe (maybe not) it is just a coincidence that the handbook talks of Step D and Mask D.

Page F2 of the handbook describes a D-STEP DUCE difference.
Page D2 of the handbook describes the DUCE support IC as Mask D.
D Step memory difference pic from the handbook.

EEC-IV-hr_17.jpg (26.04 KiB) Viewed 68699 times

I can't find any documentation suggesting that the CPU needs to be paired with or has revisions associated with the RAM/CART/DUCE chip.

Inferred from the way the memory bus works. External memory devices have to follow uP addressing. uP also needs to work with odd word access to DUCE. I've seen clear statements that words must be even. So it's another case of what was written and what happens in BINs. The documentation is very helpfull but is proving to be open to interpretation.

Is the VILE EEC using the same 81C65-D / how do its part numbers compare to the P3M?

Different. I'll add part numbers to this post when I have VILE in front of me.

20210405_171817.jpg (140.6 KiB) Viewed 68699 times

20210405_171817_1.jpg (197.96 KiB) Viewed 68699 times

EDIT; chip markings for VILE
uP
N8065EB F8
76001CCHFA
ICB780M01
L8260515 9824

ROM
N70011FWCHCA
IBA491U03
U8240257 7B0

RAM
N81C66DC F8
5021SC064
IEA782M01
L8243014

[tvrfan]

I'll just stick my 2 cents in here and say I find it VERY hard to believe that nothing changed over EEC lifetime.
I reckon we WILL find versions of 8065 which behave differently. Identifying them may be a challenge. I agree with jsa's approach that testing is the only sure fire way, but the (disassembled) bins will help too.

I reckon the manuals will have sections which are shown to be a) plain wrong, b) inconsistent/misleading, or c) outdated by later changes. Come on guys, this is real life. Mistakes happen, and sneak through the processes.

But these are going to be in the detail, the manuals are still going to be valid and massively useful for most purposes.

Hey, perhaps we can publish an addendum "8065 later changes" !

[ollopa]

Maybe (maybe not) it is just a coincidence that the handbook talks of Step D and Mask D.

Page F2 of the handbook describes a D-STEP DUCE difference.
Page D2 of the handbook describes the DUCE support IC as Mask D.
D Step memory difference pic from the handbook.

EEC-IV-hr_17.jpg

Thank you! I think that's on page C14 or somewhere near there -- I had only seen the other two pages for the DUCE and this makes it clear that there is a specific reference to the CPU.
The pocket reference is dated 1991, revision 1 whereas the software manual is dated 1990 and the hardware manual 1989.

I don't know if we're talking about changes over the lifetime of the part as much as changes during the early development and testing. Chip development is quite costly and I imagine even in the 1990's they would have tried to keep the changes to a minimum, even if there was some leeway for the high volume and mutually beneficial partnership between Ford and Intel. And while they would have produced peripheral chips with different address masks concurrently (and effectively for no additional cost), I imagine a change in the ALU would have been much more costly to design, test, and implement and my guess is that they would not have kept producing prior versions of the CPU.

P3M looks to be circa 1992. Is the VILE chip more recent?

[jsa]

Thank you! I think that's on page C14 or somewhere near there -- I had only seen the other two pages for the DUCE and this makes it clear that there is a specific reference to the CPU.
The pocket reference is dated 1991, revision 1 whereas the software manual is dated 1990 and the hardware manual 1989.

Yes C14.
No mention of word operations with odd Rb and Rd for each of the memory access modes.

P3M looks to be circa 1992. Is the VILE chip more recent?

VILE is 1998.

I've edited the VILE pic post above to add the chip markings.
Suffix F8 on both uP and RAM.

[wwhite]

Lets break this down:
- P3M is 64K, only one bank
- 8065 has RAM on chip 0x000->0x3ff
- 8065 SFRs RAM Bank0:0x0000->0x0023, RAM Bank1-3:(0x0100->0x101, 0x0200->0x0201,0x0300->0x0301) only
- 8065 General Regs Bank0:0x0024-0x00ff, RAM Bank1-3:(0x0102->0x01ff, 0x0202->0x02ff,0x0302->0x03ff) only
- 8065 External working memory is 0x0400->0x1fff
- 8065 with 64k or less, is a small scale system
- DUCE chip 81C65, external memory to the uP: R/W RAM: (0x0400->0x1fff

Accessing different ROM banks is accomplished with Bank Switching, to access different 64K banks.
P3M only has one bank, 64K, there is no program bank selecting going on.

Do we agree that the P3M hardware box only has 1 ROM bank?
Does the disassembler happen to know that with a 8065 with 1 rom bank, no rom bank switching, that a word direct odd address read, will not, and should not do any +100?

[tvrfan]

That's one of our questions - as the 8065 always has 4 REGISTER banks, even with one ROM bank, it's still technically valid, so without testing we simply don't know.