 Previous Messages |
Posted By
MCes
on 2022-12-01
11:34:09
 |  Re: plus/4 bustiming & decoding
@GeekDot
Glad to have been of help to you!
Post some pics!
|
|
Posted By
GeekDot
on 2022-11-30
02:20:38
| Re: plus/4 bustiming & decoding
HEUREKA!
Thanks to MCes I got my design working... for everybody looking for a way to properly _read_ from a C264 expansion-port:
It's "BA" (Bus Available) being high, that's what you have to look for.... well besides R/W being high, too 
So now it's onto writing some example code... stay tuned.
Thanks again to all of you!
|
|
Posted By
MCes
on 2022-11-24
12:24:22
| Re: plus/4 bustiming & decoding
@GeekDot
I don't remember how it has to be done, but if you make your registration than you can read the members mail address, so you will able to send me your documentation.
It is not clear to me your port test, I suppose that you are reading the input port that is connected to a 8 bit counter feeded with 2KHz....
If it is not a "secret", please post a link to a schematic of your I/O port (and port-test counter..)
|
|
Posted By
GeekDot
on 2022-11-23
05:29:10
| Re: plus/4 bustiming & decoding
Okayyyy... I tried what feels like 10 variations of PHI2 delay and reading still doesn't work properly.
Also the LCELL (which is ALTERA proprietary, thus not so elegant) didn't work - maybe because I'm an idiot:
signal A_internal : STD_LOGIC_VECTOR (6 downto 0);
LCA_1: LCELL PORT MAP(a_in=> PHI2, a_out=> A_internal(0));
Gen_delay_A : FOR i in 0 to 5 GENERATE
LC : LCELL PORT MAP(a_in => A_internal(i), a_out => A_internal(i+1));
END GENERATE;
i_delayedPhi2 <= A_internal(2); -- pick one of the LCELL(1-5) for ANDing it into select
Alternatively I tried to AND-in MUX ='0', also no joy 
For testing I made my external controller to continuously send about 2K of counting "1 to 10" while the plus4 compares the read data with the expected one. What it shows that it's mainly 3 bytes being dropped - the time between the drops is not totally equal, but there's a 'rough average' around 30 reads:
In -> Exp (Missing bytes) at Byte# (bytes since last drop)
3 != 6 ( 3) at 13 ( 13)
4 != 7 ( 3) at 71 ( 58)
5 != 8 ( 3) at 389 ( 318)
9 != 1 ( 2) at 410 ( 21)
2 != 5 ( 3) at 491 ( 81)
6 != 9 ( 3) at 512 ( 21)
7 != 10 ( 3) at 520 ( 8)
4 != 7 ( 3) at 534 ( 14)
3 != 6 ( 3) at 540 ( 6)
4 != 7 ( 3) at 578 ( 38)
1 != 4 ( 3) at 602 ( 24)
5 != 8 ( 3) at 633 ( 31)
2 != 5 ( 3) at 667 ( 34)
4 != 7 ( 3) at 716 ( 49)
1 != 4 ( 3) at 720 ( 4)
9 != 1 ( 3) at 755 ( 35)
3 != 6 ( 3) at 767 ( 12)
10 != 1 ( 1) at 781 ( 14)
9 != 1 ( 2) at 799 ( 18)
8 != 1 ( 3) at 856 ( 57)
6 != 9 ( 3) at 891 ( 35)
5 != 8 ( 3) at 907 ( 16)
6 != 9 ( 3) at 945 ( 38)
5 != 8 ( 3) at 981 ( 36)
3 != 6 ( 3) at 1066 ( 85)
3 != 6 ( 3) at 1093 ( 27)
2 != 5 ( 3) at 1269 ( 176)
10 != 1 ( 1) at 1604 ( 335)
10 != 1 ( 1) at 1973 ( 369)
@MCes: If you're willing to help and have some time at hand, is there a way to contact you so I could send you all my stuff (VHDL, schematic) to have a look at it?
|
|
Posted By
MCes
on 2022-11-10
11:29:33
| Re: plus/4 bustiming & decoding
About HCT/AHCT/ACT(not use HC)245...
it's not useful, the best is using the CPLD as I/O hardware on data (BUS) lines:
the CPLD pins can be setted in "LOW Slew Rate" that make them faster than the old chips but limiting the ringing noise on the data lines (noise which can be normal when long tracks are driven by a fast driver...as HCT245 is!)
|
|
Posted By
GeekDot
on 2022-11-10
07:52:07
| Re: plus/4 bustiming & decoding
@SukkoPera
Thanks for staying with me! <3
@MCes
Woohoo, it looks like that's exactly what I've been looking for! Thanks a ton... will try and come back to you!
('bout that LS245: Can't remember where, but during research I've read somewhere that a C264 prefers his databus decoupled... so I tried to behave )
|
|
Posted By
MCes
on 2022-11-09
12:04:17
| Re: plus/4 bustiming & decoding
@GeekDot
The topology of your project is not clear (a schematic could help...),
If I understood well you want an I/O port that respond at a specific address (probably the LS245 could be eliminated).
On C264 the PHI2 is not the "normal" PHI2 of a 6502 processor output, but is generated by PLA directly from PHI0:
if your devices are too fast, the reading data can be deselected by PHI2 before the correct CPU read timing.
Only for READ:
/CS has to be the decoded ADDRESS and QUALIFIED by low state of MUX or QUALIFIED by high state of PHI2 delayed by 2 or 3 CPLD LCELL (transparent registers)
https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/hdl/prim/prim_file_lcell.htm
Only for WRITE:
/CS has to be the decoded ADDRESS and QUALIFIED by high state of PHI2
Try.....
|
|
Posted By
SukkoPera
on 2022-11-09
03:43:14
| Re: plus/4 bustiming & decoding
Nope, MUX is not going to be much helpful, it basically always keeps toggling, almost like a clock signal.
What I said before probably doesn't make much sense, just ignore it. I thought you had an internal counter that gets incremented at every read, and fake reads due to memory refreshing would increment it without the actual content being provided to the software. But you would have the same problem on the C64, I guess.
|
|
Posted By
GeekDot
on 2022-11-08
15:28:18
| Re: plus/4 bustiming & decoding
siz:
You're right... It's been a typo. I'm decoding A15-A11 with that LS08.
Decoding works just fine. I'm (currently) offering $FDF0 and $FD90 via a jumper... having A10-A4 in the code, this can be changed any time.
I just picked something from http://solder-synergy.de/plus4/hardware/makers/ioarea.txt which made sense to me.
SukkoPera:
Mhhh, that sounds like a path to follow... if I interpret these lines of the
MUX also controls the holdoff of the R/W line as generated by the 7501. The R/W line is latched by the 7501 until the MUX line goes high signifying the end of the memory cycle.
So are you suggesting to watch MUX?
|
|
Posted By
siz
on 2022-11-08
09:28:42
| Re: plus/4 bustiming & decoding
Lame question:
You wrote that You decode A15-A10 as upper5 but that is 6 bits. I can't make a schematic to decode 6 bits with an LS08. (but 5 bits is ok). If you really decode 5 bits and your CPLD really decodes from A9-A3 then perhaps you miss an address bit somewhere.
But I'm not _that_ into hardware so probably I miss something.
edit: what address (range) are you trying to decode?
|
|
Posted By
SukkoPera
on 2022-11-08
07:41:02
| Re: plus/4 bustiming & decoding
I'm way far from being competent on the matter, but phi2 should be enough. I have done some decoding using GALs for my projects and that's all I use, at least.
It seems you're using address $FDF0...3, which should be fine.
Did you consider memory refresh? Maybe that hits your address too and causes havoc? Would that make sense? LOL! 
|
|
Posted By
gerliczer
on 2022-11-08
07:14:29
| Re: plus/4 bustiming & decoding
IDK. But if you are designing some hardware maybe you should try to look for hardware timing diagrams. Is a programmers' manual the best place for that?
|
|
Posted By
GeekDot
on 2022-11-08
07:00:13
| Re: plus/4 bustiming & decoding
> Bo Zimmerman
Ok... are you telling me to talk to Bo or should that mean "read the docs at http://www.zimmers.net/anonftp/pub/cbm/plus4/index.html, stupid!"
I did the latter, and wasn't able to find any direct hint. The closest I could get was this page http://www.zimmers.net/anonftp/pub/cbm/plus4/programming/manual/p19.gif telling me, that BA might be a signal to check, too. But OTOH after BA going high again during TEDs DMA dance, there are still some cycles he's doing things...
So I was hoping, that you Plus/4 guys could just tell me if phi2 can be enough (probably with some delay added) or if there's another trick up your sleeves...
Cheers,
Axel
|
|
Posted By
gerliczer
on 2022-11-08
05:10:27
| Re: plus/4 bustiming & decoding
Bo Zimmerman
|
|
Posted By
GeekDot
on 2022-11-08
03:30:39
| plus/4 bustiming & decoding
Hi all!
I'm working on a expansion card which works as a "flipper", i.e. one edge is a C64 expansion-port connector, the other is meant for a C264 machine.
While the C64 end works just fine, I'm experiences data-losses during reads on the C264 side  - which I handled (because I have no experience nor proper docs) like a C64..
For the tests, reading is done by simple BASIC peek - reading about 64kb I have "dropouts" of mostly ~3 bytes about every 250-300 bytes.
For decoding I'm using an LS08 for A15-A10 and do the rest in a CPLD.
So the VHDL decodes a select using the single output of the LS08 (upper5), C16option is a jumper and i_AddrHi are A9-A3:
i_Select <= '1' when ( upper5 = '1' and C16option = '0' and i_AddrHi = "1011111" ) else '0';
[...]
This Signal is also used (inverted) for an LS245 buffering D0-7 on the card
My Chipselect for the data providing chip is then using i_Select, A3&A2 and phi2:
myCS <= '0' when ( i_Select = '1' and i_AddrLo = "00" and phi2 = '1' ) else '1';
I assume that phi2 is not enough on a C264 port?
Thanks in advance for any idea and helping & Cheers,
Axel
|
|
