6502.org Forum Projects Code Documents Tools Forum
It is currently Sat Oct 05, 2024 4:43 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Hardware

All times are UTC




Post new topic Reply to topic  Page 3 of 5
  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
  Previous topic | Next topic 
Author Message
fachat
PostPosted: Wed May 11, 2022 9:03 pm 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1041
Location: near Heidelberg, Germany
I still wonder what is the reason behind the interrupt priority logic?

Because, typically each chip has its own interrupt enable flag, so can be disabled independently - not just by priority.
The CPU does not have interrupt priority levels. It even doesn't really know if it's in an interrupt routine - just if interrupts are allowed or not.

So when I need higher and lower priority interrupts, my single interrupt routine checks each interrupt source in turn with decreasing priority. Iff I really need some short high prio interrupt handling, lowest prio interrupt routine would even allow interrupts again during interrupt processing.

The only reason I could think of your approach is to being able to very quickly identify an interrupt source? Or are you planning on using some specific high speed devices that may require such ultra fast and/or prioritized interrupt handling?

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/
Top
 Profile  
Reply with quote  
fachat
PostPosted: Wed May 11, 2022 9:22 pm 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1041
Location: near Heidelberg, Germany
It always gives me pain when I see a serial communication protocol being bit-banged. Especially as you don't use the VIA shift register at all...
Typically I use data out (IIRC CB2) as MOSI, clock out (CB1) as SPI clock, and a separate 8bit serial to parallel shift register for MISO, and read out the incoming data with a parallel port PA or PB. Now I notice you already need the port lines but I wonder if the SPI select lines could be implemented using a second serial to parallel shift register listening to MOSI, using CA2 to switch between SPI data out and select line out. A little bit of hardware but so much faster.
(And with some xor tricks you can get all four spi modes even!)

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Wed May 11, 2022 10:30 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1383
Examining the latest (again), you still didn't correct the UART decoding... it starts at $D090, not $D010.

One thing that stands out is your desire to use as many '138 decode chips as possible (9 in total). What baffles me is why... perhaps you have an unlimited stock of them.

As a suggestion, if you can program an ATF22V10C (or equivalent) PLD chip, you can replace all of the '138 chips, the '08 and the recently added '02 chip with a single ATF22V10C. This saves 10 chips and the board space they take. It would also give you a flexible memory map should you want to change anything at a future date, without having to change your hardware design and/or PCB.

Second suggestion, you can replace the 555 timer (plus associated parts) and the '04 inverter with a 3-pin DS1813. That would leave one last '04 inverter in use in the IRQ circuitry. You can replace that with a single mosfet and delete the 74HCT04 as well.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
DarkestSoul1992
PostPosted: Sat May 14, 2022 8:56 pm 
Offline
User avatar

Joined: Mon Dec 20, 2021 3:01 am
Posts: 17
Location: Glasgow, UK
I wanted this to be simple to understand and learn as well as simple to build and I'm trying to find the balance. The 138s simply allowed for a lower chip count while having a simple logic table. This should be the kind of thing that could be used at work but built in school. I hope that better explains the rationale behind my decisions.
As for the decoding logic, I read that as A7\ A6\ A5\ A4 = O1\ or 0001 as Y where xxxx xxxx YYYY xxxx or something like that. Could you please explain where I made my mistake? I just don't seem to see it...
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Sat May 14, 2022 9:37 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1383
I was looking at what you had on GitHub 3 days ago, you since changed it. As for simplicity, yes the '138 3-to-8 decoder is a nice device, but you're using 9 of them and making a separate decode chip for each I/O device. This defeats the lower chip count claim. Back in the 80's, I built a CPU card with an expansion connector... it used 3 chips for logic decoding and a qualified memory write line. It had 8 chip selects using a single 74LS138 and they could be 16- or 32-bytes wide. I also defined an I/O page at $FE00. Here's a simple schematic of the 3-chip logic:

Attachment:
Screen Shot 2022-05-14 at 5.28.55 PM.png
Screen Shot 2022-05-14 at 5.28.55 PM.png [ 165.67 KiB | Viewed 895 times ]


Note that the memory map was 32KB of RAM from $0000 - $7FFF with it's chip select line tied to A15. The ROM was also 32KB but the decode logic diverts the $FE00 - $FEFF addresses to the I/O select, which drives the 74LS138. I later went with 32-byte wide I/O selects as there are some newer devices which have more than 16 registers (e.g. the NXP DUARTs). The above schematic clip is a refresh of that same design done with all CMOS chips about 10 years ago. I've actually run this CPU board with an I/O board (65C22 + 65C51) at speeds up to 10MHz.

Hope this helps...

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
DarkestSoul1992
PostPosted: Sun May 15, 2022 2:05 am 
Offline
User avatar

Joined: Mon Dec 20, 2021 3:01 am
Posts: 17
Location: Glasgow, UK
Quote:
I was looking at what you had on GitHub 3 days ago, you since changed it.


Ah, I change a lot so I don't remember all of my commits but I do now remember changing it along with the CS_DEV address.

Quote:
This defeats the lower chip count claim.


I meant lower than the previous design but I do have some ideas on lowering it further while keeping the simplicity. Failing that, I will check out PLDs and probably use one.

Quote:
Second suggestion, you can replace the 555 timer (plus associated parts) and the '04 inverter with a 3-pin DS1813.

Thanks for showing me this, could be a game changer for me as most people just want to turn it on and use it rather than pressing buttons before being able to do anything...

Quote:
Back in the 80's, I built a CPU card with an expansion connector... it used 3 chips for logic decoding and a qualified memory write line.


I will also go over the schematics for my CPU I was designing (just for the hell of it) a couple of years back, your design reminded me (minus the 138) of the instruction decoder and there was some pretty interesting logic used there to lower the percentage of the FPGA used.

UPDATE: Managed to reduce the number of 138s to only 4. 3 for device selection in general and one specifically for the IRQ priority.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Sun May 15, 2022 5:42 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8411
Location: Midwestern USA
DarkestSoul1992 wrote:
UPDATE: Managed to reduce the number of 138s to only 4. 3 for device selection in general and one specifically for the IRQ priority.

In your application, I see no value in hardware IRQ priority. You don't have anywhere near enough I/O to justify it. I suggest you spend your chip budget on useful features, not bells and whistles.

BTW, everything you are trying to do in discrete logic can be accomplished in a single Microchip ATF1504AS CPLD—and with substantially better performance.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
DarkestSoul1992
PostPosted: Sun May 15, 2022 7:18 pm 
Offline
User avatar

Joined: Mon Dec 20, 2021 3:01 am
Posts: 17
Location: Glasgow, UK
BigDumbDinosaur wrote:

In your application, I see no value in hardware IRQ priority. You don't have anywhere near enough I/O to justify it. I suggest you spend your chip budget on useful features, not bells and whistles.

BTW, everything you are trying to do in discrete logic can be accomplished in a single Microchip ATF1504AS CPLD—and with substantially better performance.


I am currently looking at the datasheet for the ATF22V10C PLD as it was recommended and has a DIP pin configuration. The ATF1504AS is PLCC or TQFP. I have experience with CPLDs and FPGAs from when I designed my own processor. (For funsies.) So shouldn't be hard to work out.
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Sun May 15, 2022 8:28 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1383
For the ATF22V10C, take a look at my C02 Pocket SBC... it has a full config for the 22V10 which provides qualified memory Read and Write signals, RAM and ROM selects plus 5- I/O selects that are 32-bytes wide each. You can easily change the ranges to suite what you want/need. No need to reinvent the wheel.

Code:
Name     Glue3 ;
PartNo   01 ;
Date     10/31/2017 ;
Revision 01 ;
Designer KM ;
Company  Analogue Technologies ;
Assembly SBC2 ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN 1    = CLK                       ; /*                                 */
PIN 2    = A15                       ; /*                                 */
PIN 3    = A14                       ; /*                                 */
PIN 4    = A13                       ; /*                                 */
PIN 5    = A12                       ; /*                                 */
PIN 6    = A11                       ; /*                                 */
PIN 7    = A10                       ; /*                                 */
PIN 8    = A9                        ; /*                                 */
PIN 9    = A8                        ; /*                                 */
PIN 10   = A7                        ; /*                                 */
PIN 11   = A6                        ; /*                                 */
PIN 13   = A5                        ; /*                                 */
PIN 23   = RW                        ; /*                                 */

/* *************** OUTPUT PINS *********************/
PIN 14   = !IO1                      ; /*                                 */
PIN 15   = !IO2                      ; /*                                 */
PIN 16   = !IO3                      ; /*                                 */
PIN 17   = !IO4                      ; /*                                 */
PIN 18   = !IO5                      ; /*                                 */
PIN 19   = !ROM                      ; /*                                 */
PIN 20   = !RAM                      ; /*                                 */
PIN 21   = !MWR                      ; /*                                 */
PIN 22   = !MRD                      ; /*                                 */

/** Declarations and Intermediate Variable Definitions  **/
FIELD ADDRESS = [A15..0];

RAM = ADDRESS:['h'0000..7FFF];
IO1 = ADDRESS:['h'FE00..FE1F];
IO2 = ADDRESS:['h'FE20..FE3F];
IO3 = ADDRESS:['h'FE40..FE5F];
IO4 = ADDRESS:['h'FE60..FE7F];
IO5 = ADDRESS:['h'FE80..FE9F];
ROM = ADDRESS:['h'8000..FDFF]
        # ADDRESS:['h'FEA0..FFFF];
/** Logic Equations **/
MWR = (CLK & !RW);
MRD = (CLK & RW);


I always mention Peter (CBSCPE) on the Field Address part for simplifying the address decoding. On a slightly different note, I would also suggest using the qualified Read and Write lines for all memory, (RAM and EEPROM) and separate the CS and OE lines. Also note that you can use code to program the EEPROM insitu, making software updates easier. I have code in my C02 Monitor which allows this, have fun.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
DarkestSoul1992
PostPosted: Sun May 15, 2022 9:54 pm 
Offline
User avatar

Joined: Mon Dec 20, 2021 3:01 am
Posts: 17
Location: Glasgow, UK
As always very grateful for the help and floobydust especially for giving me food for thought and being patient. Prime example of what people on this forum are like as I have only had the best help and advice from all of you. Many thanks.

P.S. The documentation, even though incomplete, should be more in order now and is located here: https://thealmostgenius.geekgalaxy.com/WolfNet-6502-WBC.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Mon May 16, 2022 1:00 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8411
Location: Midwestern USA
DarkestSoul1992 wrote:
I am currently looking at the datasheet for the ATF22V10C PLD as it was recommended and has a DIP pin configuration. The ATF1504AS is PLCC or TQFP. I have experience with CPLDs and FPGAs from when I designed my own processor. (For funsies.) So shouldn't be hard to work out.

With the 22V10C, some pins are only inputs and remaining pins are (potentially) bi-directional. With the 1504 in PLCC44, 28 of the 32 user pins are bi-directional. That confers a lot of flexibility in a package that is scarcely larger than the 22V10. The other considerations are the 1504 has many times the logic resources of any GAL, faster pin-to-pin prop time (7.5ns) and a JTAG port.

At one point, I considered using a GAL for glue logic, but reconsidered after look at the specs for the ATF150x series of CPLDs. My nearly finished POC V2.0 will being using a 1504 in PLCC.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Mon May 16, 2022 2:00 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1383
Needless to say, the ATF1504 is certainly a more capable chip and would allow a more complex level of glue logic. But it seems the ATF22V10 can easily provide ample glue logic for the motherboard and associated I/O devices. The datasheet does show a part spec as low as 5ns prop time. Seems more programmers are able to program the Atmel (now Microchip) ATF22V10 and ATF16V8 chips, while the 1504 and others need the separate programmer (I bought one some time ago myself... as I plan to try the 1504 and 1508 devices at some point).

Any additional I/O would be added via adapter cards and would have to have it's own decode logic. You do need to ensure your glue logic provides empty address space for any adapter requirements, if and when you add them.

Additional comments to the latest motherboard update:

1- You don't need two chip selects going to each I/O device. Just tie the CS1 lines on the 65C22 and 65C51 devices to Vcc and configure the 22V10 for active low outputs, which go to /CS2.
2- Split the lines between CS and OE on the EEPROM memory devices... OE goes to the qualified read from the 22V10 and CS becomes a dedicated chip select from the 22V10.
3- You can remove the last '138 decoder that was configured for memory read and write lines (the 22V10 replaces that too).
4- On EEPROM devices, put in a jumper for the WE pin, either to Vcc which makes it Read Only, or to the qualified write signal from the 22V10. This allows programming insitu by swapping the jumper.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
DarkestSoul1992
PostPosted: Tue May 17, 2022 2:48 pm 
Offline
User avatar

Joined: Mon Dec 20, 2021 3:01 am
Posts: 17
Location: Glasgow, UK
So, 2.6 is done now and the sound card has been updated to 1.2. Now in the process of devising a breadboard expansion card.
Another question that may spark friendly debate is: What patterns can you recommend for pre-routed traces on a breadboard? (Pictures if possible...)
Top
 Profile  
Reply with quote  
DarkestSoul1992
PostPosted: Tue May 17, 2022 8:55 pm 
Offline
User avatar

Joined: Mon Dec 20, 2021 3:01 am
Posts: 17
Location: Glasgow, UK
As promised, version 2.6 in colour and monochrome for schematics and monochrome for the PCB layout.


Attachments:
Motherboard-Assembly.pdf [774.45 KiB]
Downloaded 47 times
Motherboard - Schematic Monochrome.pdf [728.9 KiB]
Downloaded 33 times
Motherboard - Schematic Colour.pdf [741.02 KiB]
Downloaded 38 times
Top
 Profile  
Reply with quote  
floobydust
PostPosted: Wed May 18, 2022 12:46 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1383
1- Suggest you look at the 65SIB W65C22... still showing incorrect CS0 and /CS1.

2- I still recommend you split the OE and CS lines on the EEPROM devices and use the qualified read line from the 22V10. connected to OE.

3- On the PCB, suggest you use high quality sockets for the EEPROM devices, not ZIF sockets. You can always insert a ZIF socket into the standard socket when you need it.

4- Finally, again... use a jumper for the EEPROM write signal, either to Vcc or to the qualified write signal from the 22v10. You'll have a a more flexible and usable setup.

5- Would add a 3,3K from Reset to Vcc. Yes, the DS-1813 has an internal pull-up, but I think it's around 5K or higher. A little extra helps. I use a resistor network for the pull-ups and use one to drive a power on LED (1ma LED).

Last... are you really sure on using the W65C51? You have to code around the problem, so why not use a more modern and better UART/DUART. As you're also using a RS-232 level converter to interface to a DB-9 serial port, exactly what are you planning to use that port for? Driving some older device or perhaps as a serial console? Also, suggest you test your 22V10 configuration before making PCBs... verifying what you expect it to do.

_________________
Regards, KM
https://github.com/floobydust
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 3 of 5
  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

Board index » 6502.org Users Forum » Hardware

All times are UTC


Who is online

Users browsing this forum: No registered users and 13 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:  
6502.org is an ongoing project by Mike Naberezny and contributors.