6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:09 pm

All times are UTC




Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 9  Next
Author Message
PostPosted: Wed Apr 05, 2017 7:47 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
I just tried disabling channel A, and it didn't change anything. I'l leave it like that though.


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 10:27 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
If for some reason your /CS signal is not working properly, all attemps accessing the DUART will fail. I scanned the datasheet and found that there is an input register that simply reflects the state of the IPs. Perhaps you could try to read this register and "echo" it to your working VIA, where you can see (LEDs) whats the matter. Doing this within a loop you should also verify changes when you connect one DUART IPx to Vcc or GND.


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 12:42 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
GaBuZoMeu wrote:
you could try to read this register and "echo" it to your working VIA, where you can see (LEDs) whats the matter. Doing this within a loop you should also verify changes when you connect one DUART IPx to Vcc or GND.
That sounds like a good idea.

If that test is not successful then you'll definitely want to verify the DUART /CS signal. There are many ways to do that. One simple way is to connect the /CS signal to the RDY input on the CPU. This will cause the system to permanently halt when the /CS signal goes low (the first time the DUART is accessed). The CPU address lines should freeze, with the DUART address appearing on them.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 4:57 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
In your schematic, I don't see a connection to NMIB on the 65C02.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 10:05 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
GaBuZoMeu wrote:
you could try to read this register and "echo" it to your working VIA, where you can see (LEDs) whats the matter. Doing this within a loop you should also verify changes when you connect one DUART IPx to Vcc or GND.

I'll have a go. I can modify my VIA test program to do that on the other port as well.
Dr Jefyll wrote:
If that test is not successful then you'll definitely want to verify the DUART /CS signal. There are many ways to do that. One simple way is to connect the /CS signal to the RDY input on the CPU. This will cause the system to permanently halt when the /CS signal goes low (the first time the DUART is accessed). The CPU address lines should freeze, with the DUART address appearing on them.

Good thing I pulled up RDY, rather than tied it. I can do that.

BigDumbDinosaur wrote:
In your schematic, I don't see a connection to NMIB on the 65C02.

That must be another omission that I missed. It is pulled up to Vcc with a 3.3Kohm resistor.


Top
 Profile  
Reply with quote  
PostPosted: Wed Apr 05, 2017 10:35 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
DerTrueForce wrote:
BigDumbDinosaur wrote:
In your schematic, I don't see a connection to NMIB on the 65C02.

That must be another omission that I missed. It is pulled up to Vcc with a 3.3Kohm resistor.

Okay. Thought that maybe the 'C02 was hung on an NMI with no way to service it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 06, 2017 3:09 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
OK, so in checking the VIA mirroring program(the listing file), I discovered that the SB-Assembler ends expressions at spaces.
Because I was using expressions like "DUART.SRA = DUART + 1", that was interpreted as "DUART.SRA = DUART". As a result, all the DUART accesses were to its base address, that is, Mode Register A. I'll fix that and see if it works.

This is a good thing; it means I'm learning.

EDIT: Nope, it did not work. Still nothing. But the X-spitter program looks correct now.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 06, 2017 4:57 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
DerTrueForce wrote:
...
This is a good thing; it means I'm learning.
...

:)
Perhaps you should additionally post a memory dump of your programs. Are you shure that your interrupt vector settings are assembled correctly? Dump them too. It would be pretty sobering if just wrong assembly causes all your trouble. Most people here are familiar with some basic instructions machine codes - without refering a list.

If the read inputs write to VIA ORB didn't work either you should try Dr. Jefylls idea of connecting /CS to RDY and then probing all address lines. Perhaps then the mist clouds vanishes.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 06, 2017 7:24 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
Memory dump? Do you mean a hex listing? I can do that; the assembler produces a list file, and I can put that up, along with the Intel Hex file I used to write the EEPROM. Or I could dump it. What would be best? (I suspect dumping the ROM would be.)

I still need a list for all the instructions, but I have a few 'cheat' sheets with relevant info on 'em. One is for asm-to-hex, one is for hex-to-asm, and one is info on the hardware I'm using(register locations and functions, mostly). Much easier to use than the datasheets, for most of my purposes. And I kept the datasheets and programming manual, because I still need them occasionally.

I haven't tried the new 'echo' program yet. I finished testing the fixed program, and then got caught up in work. I put it off because I have to dump all my EEPROMs to find one I don't mind erasing(I have 5 of them). I also think a couple are duds, so I want to test those too, when I get time.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 06, 2017 1:59 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
DerTrueForce wrote:
I have to dump all my EEPROMs to find one I don't mind erasing

FWIW, you don't need a fresh EPROM to try the idea of connecting /CS to RDY. You can use an existing EPROM as long as the code it contains will access the DUART.

When the DUART access occurs /CS should go low and remain low 100% (until you reset). This'll be easy to verify with a meter. If you aren't able to see this behavior then maybe something is preventing activity on /CS.

It's also possible you'll find inappropriate /CS activity -- ie, /CS will go low and halt the system without the UART address appearing on the bus.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 06, 2017 3:44 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
Dr Jefyll wrote:
It's also possible you'll find inappropriate /CS activity -- ie, /CS will go low and halt the system before the UART address appears on the bus.

That's why I ask if he could put up the logic equations for the GAL. It could be there's a sneaky little error that is behind all this.

Or, it could be the configuration of the DUART isn't correct. Needless to say, I've been down that road at least once. :oops:

If I have some time today (those pesky varmints called "clients" have a way of "stealing" my time :D) I will post the setup values I used on POC V1.1, which has the 28L92 running at 115.2Kbps on both channels, along with the counter/timer generating a 100 Hz IRQ.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 06, 2017 3:48 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
DerTrueForce wrote:
I can't find the code I used for the GAL, but I remember how it works. The chip selects are all generated by the address lines and nothing else. I'm synthesizing /RD and /WR, both from Phase 2 and R/W. RES is generated by inverting /RES.

Two questions:

  1. Are you using a WDC 65C02 or some other brand? I ask because I couldn't quite make out the label for the MPU in your schematic.

  2. Which brand of GAL are you using?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: NXP 28L92 Setup
PostPosted: Thu Apr 06, 2017 4:44 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
It turned out I could extract some sections from the firmware listing file for POC V1.1 and provide information that might help you.

Code:
01134    ;PHILIPS/NXP MULTIPLE CHANNEL UART CONFIGURATION & CONTROL CONSTANTS
01135    ;
01136    ;   —————————————————————————————————————————————————————————————————————
01137    ;   This file contains definitions that are used in DUART & QUART setup
01138    ;   tables.  Any changes to device configuration should be made herein, &
01139    ;   no changes should be made to the setup tables themselves unless a new
01140    ;   function is being added or an existing function is being removed.
01141    ;
01142    ;   The constants in this file are applicable to the 26C92, 28L92 & 28C94
01143    ;   only.  Consult with the appropriate data sheets before changing any-
01144    ;   thing & be sure to make a backup copy of this file before you do make
01145    ;   changes.  DO NOT use this setup data with the 2692!
01146    ;
01147    ;   The values used to select baud & counter/timer (C/T) rates are based
01148    ;   upon use of the recommended 3.6864 MHz X1 clock.
01149    ;   —————————————————————————————————————————————————————————————————————
01150    ;
01151      4000             nxx1freq =3686400              ;X1 clock frequency in Hz
01152      2000             nxctscal =nxx1freq/2           ;C/T scaled clock
01153    ;
01154    ;
01155    ;   ACR — auxiliary control register
01156    ;
01157      0060             nxparbrt =@01100000            ;...
01158    ;
01159    ;   a) Use baud rate table #1 —— see data sheet.
01160    ;   b) C/T acts as a timer.
01161    ;   c) C/T clock source is scaled to X1 ÷ 1.
01162    ;
01163    ;
01164    ;   CR — command register...
01165    ;
01166      0001             nxpcrrxe =@00000001            ;enable receiver
01167      0002             nxpcrrxd =@00000010            ;disable receiver
01168      0004             nxpcrtxe =@00000100            ;enable transmitter
01169      0008             nxpcrtxd =@00001000            ;disable transmitter
01170      0010             nxpcrmr1 =@00010000            ;select MR1
01171      0020             nxpcrrxr =@00100000            ;reset receiver
01172      0030             nxpcrtxr =@00110000            ;reset transmitter
01173      0040             nxpcresr =@01000000            ;reset error status
01174      0050             nxpcrbir =@01010000            ;reset received break change IRQ
01175      0060             nxpcrbks =@01100000            ;start break
01176      0070             nxpcrbke =@01110000            ;stop break
01177      0080             nxpcrrsa =@10000000            ;assert request to send
01178      0090             nxpcrrsd =@10010000            ;deassert request to send
01179      00A0             nxpcrtme =@10100000            ;select C/T timer mode
01180      00B0             nxpcrmr0 =@10110000            ;select MR0
01181      00C0             nxpcrtmd =@11000000            ;select C/T counter mode
01182      00E0             nxpcrpde =@11100000            ;enable power-down mode — CRA only
01183      00F0             nxpcrpdd =@11110000            ;disable power-down mode — CRA only
01184    ;
01185    ;   ————————————————————————————————————————————————————————————————————————
01186    ;   NXPCRPDD & NXPCRPDE apply to the 26C92 & are reserved in the 28L92 & the
01187    ;   28C94.  These parameters should not be used in any setup function.  They
01188    ;   are listed here only for reference purposes.  A hard reset automatically
01189    ;   brings the device out of power-down mode.
01190    ;   ————————————————————————————————————————————————————————————————————————
01191    ;
01192    ;
01193    ;   CSR — clock select register...
01194    ;
01195      0066             nxpcsdef =@01100110            ;RxD & TxD at 115.2 Kbps...
01196    ;
01197    ;   ————————————————————————————————————————————————————————————————
01198    ;   The above data rate is based upon the value of NXPARBRT (above).
01199    ;   ————————————————————————————————————————————————————————————————
01200    ;
01201    ;
01202    ;   CT — counter/timer...
01203    ;
01204      4800             nxpctdef =nxctscal/hz          ;HZ underflows per second
01205      0000             nxpctdlo =<nxpctdef            ;underflows/sec LSB
01206      0048             nxpctdhi =>nxpctdef            ;underflows/sec MSB
01207    ;
01208    ;
01209    ;   MR0 — mode 0 register...
01210    ;
01211    ;         .if .ref(nx28l92)
01212      00CC             nxpm0def =@11001100            ;if using a 28L92 ...
01213    ;
01214    ;   11001100
01215    ;   ||||||||
01216    ;   |||||+++———> extended baud rate #2
01217    ;   ||||+——————> 16-deep FIFO
01218    ;   ||++———————> TxD interrupts only when FIFO is empty
01219    ;   |+—————————> RxD interrupts only when FIFO is full (see also MR1:6)
01220    ;   +——————————> enable RxD watchdog timer
01221    ;
01222    ;         .else
01223    ;nxpm0def =@11000100            ;if using a 26C92 or 28C94...
01224    ;
01225    ;   11000100
01226    ;   ||||||||
01227    ;   |||||+++———> extended baud rate #2
01228    ;   ||||+——————> not used
01229    ;   ||++———————> TxD interrupts only when FIFO is empty
01230    ;   |+—————————> RxD interrupts only when FIFO is full (see also MR1:6)
01231    ;   +——————————> enable RxD watchdog timer
01232    ;
01233    ;         .endif
01234    ;
01235    ;
01236    ;   MR1 — mode 1 register...
01237    ;
01238      00D3             nxpm1def =@11010011            ;...
01239    ;
01240    ;   11010011
01241    ;   ||||||||
01242    ;   ||||||++———> 8 bit char size
01243    ;   |||||+—————> parity type (ignored)
01244    ;   |||++——————> no parity generated or checked
01245    ;   ||+————————> character error mode
01246    ;   |+—————————> RxD interrupts only when FIFO is full (see also MR0:6)
01247    ;   +——————————> RxD controls RTS
01248    ;
01249    ;   MR2 — mode 2 register...
01250    ;
01251      0017             nxpm2def =@00010111            ;normal mode, auto RTS
01252    ;
01253    ;
01254    ;   OPCR — output port configuration register...
01255    ;
01256      0000             nxpopdef =@00000000            ;no operation
01257    ;
01258    ;
01259    ;   combined setup commands...
01260    ;
01261      000A             nxpcrrtd =nxpcrtxd|nxpcrrxd    ;disable transmitter & receiver
01262      0005             nxpcrrte =nxpcrtxe|nxpcrrxe    ;enable transmitter & receiver

The above sets the patameters used to configure the 28L92 at reset. HZ equals 100, which is the jiffy IRQ rate I use for timekeeping purposes. The symbol @, as in @00010111, is the radix for binary in the Kowalski assembler.

Parameters from the above table are used in the following data table:

Code:
10988    ;PHILIPS/NXP DUAL UART INITIALIZATION DATA
10989    ;
10990    ;   ————————————————————————————————————————————————————————————————————————
10991    ;   The following data table is used to initialize the 26C92 & 28L92 DUARTs
10992    ;   following reset.  Each entry in this table consists of a chip register
10993    ;   offset paired with the parameter that is to be loaded into the register.
10994    ;   Table entries are read in reverse order during device setup.
10995    ;
10996    ;   Parameters are defined in include_hardware/uart/nxp_constants.asm & are
10997    ;   to be modified there, not here.  Only edit this table if you need to add
10998    ;   or remove an entry.  Be sure to back up nxp_constants.asm before editing
10999    ;   it!
11000    ;
11001    ;   NOTE: The data in nxp_constants.asm cannot be used to configure the 2692
11002    ;         DUART, as it does not have TxD FIFOs.
11003    ;   ————————————————————————————————————————————————————————————————————————
11004    ;
11005    nxpsutab .byte nx_imr, nxpiqmsk  ;IMR (enables IRQs)
11006             .byte nx_ctu, nxpctdhi  ;CTU
11007             .byte nx_ctl, nxpctdlo  ;CTL
11008             .byte nx_crb, nxpcrtxe  ;CRB
11009             .byte nx_csrb,nxpcsdef  ;CSRB
11010             .byte nx_mrb, nxpm2def  ;MR2B
11011             .byte nx_mrb, nxpm1def  ;MR1B
11012             .byte nx_crb, nxpcrmr1  ;CRB
11013             .byte nx_mrb, nxpm0def  ;MR0B
11014             .byte nx_crb, nxpcrmr0  ;CRB
11015             .byte nx_cra, nxpcrrsa  ;CRA
11016             .byte nx_cra, nxpcrrte  ;CRA
11017             .byte nx_csra,nxpcsdef  ;CSRA
11018             .byte nx_mra, nxpm2def  ;MR2A
11019             .byte nx_mra, nxpm1def  ;MR1A
11020             .byte nx_cra, nxpcrmr1  ;CRA
11021             .byte nx_mra, nxpm0def  ;MR0A
11022             .byte nx_cra, nxpcrmr0  ;CRA
11023             .byte nx_acr, nxparbrt  ;ACR
11024             .byte nx_opcr,nxpopdef  ;OPCR
11025             .byte nx_crb, nxpcrtmd  ;CRB
11026             .byte nx_crb, nxpcresr  ;CRB
11027             .byte nx_crb, nxpcrbir  ;CRB
11028             .byte nx_crb, nxpcrtxr  ;CRB
11029             .byte nx_crb, nxpcrrxr  ;CRB
11030             .byte nx_crb, nxpcrrsd  ;CRB
11031             .byte nx_cra, nxpcrtmd  ;CRA
11032             .byte nx_cra, nxpcresr  ;CRA
11033             .byte nx_cra, nxpcrbir  ;CRA
11034             .byte nx_cra, nxpcrtxr  ;CRA
11035             .byte nx_cra, nxpcrrxr  ;CRA
11036             .byte nx_cra, nxpcrrsd  ;CRA
11037             .byte nx_cra, nxpcrpdd  ;CRA
11038             .byte nx_imr, 0         ;IMR (disable IRQs)
11039      0044             s_nxptab =*-nxpsutab

The way the above table works is the first value following each .byte pseudo-op, e.g., NX_IMR, is the zero-based register number. The second value is the parameter that is to be loaded into the register, said parameter having been defined in the previous table. The table is read in reverse order, which means the first operation to be performed on the DUART is the disabling of interrupts (line 011039). The expression *-NXPSUTAB calculates the number of bytes in the table, which is used in the code that actually reads the table.

Speaking of code, here is the eight bit version of the assembly language I used to configure the DUART:

Code:
03398    ;   configure DUART...
03399    ;
03400    E0B1  A0 42                 ldy #s_nxptab-s_word  ;DUART setup table index (S_WORD = 2)
03401    ;         
03402    E0B3  BE F4 F8     .0000090 ldx nxpsutab,y        ;get register
03403    E0B6  B9 F5 F8              lda nxpsutab+s_byte,y ;get parameter (S_BYTE = 1)
03404    E0B9  9D 00 D0              sta io_acia,x         ;write to register (IO_ACIA defines the DUART's base address)
03405    E0BC  EA                    nop
03406    E0BD  EA                    nop
03407    E0BE  EA                    nop
03408    E0BF  EA                    nop
03409    E0C0  EA                    nop
03410    E0C1  88                    dey
03411    E0C2  88                    dey
03412    E0C3  10 EE                 bpl .0000090          ;next register
03413    ;
03414    E0C5  AD 0E D0              lda io_acia+nx_sct    ;start C/T &...
03415    E0C8  58                    cli                   ;allow IRQs

The delay caused by the five NOPs gives the DUART ample time to react to each loaded parameter, assuming Ø2 does not exceed 14 MHz. Actually, the delay is only required when the most significant nybble of a command register is accessed (the data sheet says each write to a command register should be separated by three X1 clock edges, which is slightly inaccurate—the separation should be for three consecutive falling edges, or 272 nanoseconds, assuming X1 is 3.6864 MHz). However, it's more convenient to execute a delay on every write—less code is required, and the execution time isn't significantly degraded.

When interrupts are enabled at line 03415 the counter/timer will be producing a 100 Hz jiffy IRQ, which is the timekeeping base for the system.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 06, 2017 11:22 pm 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
BigDumbDinosaur wrote:
Are you using a WDC 65C02 or some other brand? I ask because I couldn't quite make out the label for the MPU in your schematic.

Which brand of GAL are you using?[/list]

I am indeed using the WDC 65C02. I didn't write that into the schematic.
The GAL is an Atmel ATF16V8B.
I suspect that the CUPL equations for the 16V8 are on the computer I used to use. I'll have to see.

I've gone and dumped the rom I've been using, and I found what looked very like an intel hex file in the ASCII pane of my hex editor. :oops: Turns out that there are two commands. One deals with binary files, and the other deals with hex files. I used the appropriate command, and now the correct stuff gets written to the EEPROM, but it still doesn't work. I'll try tying the /CS and RDY together, as has been suggested. If that does wierd things, I'll hit it with the single-cycler, and see what goes on. I dumped the ROM after I wrote it, because the programming software gave a verify error, but when I checked it, it matched the list file's assembly, so I think that means it's good.


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 07, 2017 2:17 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
DerTrueForce wrote:
The GAL is an Atmel ATF16V8B.
I suspect that the CUPL equations for the 16V8 are on the computer I used to use. I'll have to see.

Are you aware that most burners cannot correctly program Atmel GALs? Atmel GALs require the use of a non-standard (i.e., proprietary) programming algorithm. A burner that can correctly program an Atmel GAL is an expensive piece of hardware, typically around 500USD. The programming run with the inexpensive types of burners many hobbyists use seems to be successful but the GAL ends up being non-functional. Unless you had access to the proper type of burner, it's highly likely your GAL is the culprit.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 132 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 9  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: