I've created the Memory Map, truth tables and resulting decoder logic, and a rough schematic of just the address bus, clocks and decoders with the w65c02, w65c51, EEPROM and RAM. Parts are starting to arrive so hopefully I'll be able to start the build soon. I've been drawing and redrawing these for a couple of days. If anybody gets a chance can you give it a quick once over to make sure I didn't do something stupid. This is my first build for one of these.

I see a couple of likely problems:

1. The CD4002 is a very slow part, far slower than the rest of the logic. At 5 volts, the minimum prop time is 125ns and could be as slow as 250ns. Unless you plan to run the machine at a crawl this is not acceptable performance. It might not be able to reliably function with a 1 MHz Ø2 clock.
   
   
2. The use of Ø2 to qualify selection of the 74xx138 is unnecessary and in fact, will not work as expected. The 65C51 must be selected before the rise of Ø2, else it will fail to respond to the MPU. See below about qualifying read/write with the clock.
   
   
3. You have /WE on the SRAM directly wired to RWB on the MPU, with /CE being driven by the 74xx138 decoder. By eliminating the clock signal to the decoder, the SRAM will be selected as soon as a valid address appears, which will be before the rise of the clock. What should be qualified by Ø2 when accessing non-65xx I/O device is read/write, especially a write operation. The reasons are several:
   
   
   1. The address bus will be changing during Ø2 low and the potential exists for a wild write if /WE is low before the address bus is fully settled.
      
      
   2. The data bus is not guaranteed to be valid when Ø2 is low. If you enable writing while Ø2 is low an undefined operation might occur in the hardware as the data (and address) bus settles.
   
   Note that 65xx peripherals, such as the 65C22, understand the 65xx bus cycle and its relationship to the clock, and are not to be qualified by Ø2.
   
   A typical read/write circuit for use with non-65xx peripherals is as follows:
   
   
   Attachment:
   File comment: Read/Write for Asynchronous Devices
   
   x86_read_write.gif [ 19.73 KiB | Viewed 2294 times ]
   
   
   
4. Similarly, the ROM should be selected during Ø2 low, as you are doing, but its output should not be enabled until Ø2 high so as to give the address bus time to settle. The above read/write circuit also accounts for this; connect /RD to /OE on the ROM, as well as on the SRAM.
   
   
5. I recommend using a 74HC138 decoder. 74AC hardware generates extremely fast edges, which may cause a variety of problems, especially ringing, if physical construction is not on a multi-layer PCB or a well-designed wire-wrap layout.

I'm not sure I understand why you have such a strange memory map. Also, are you aware that the 65C51 as produced by WDC contains a serious hardware bug?

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

Ditto to everything BDD posted.

You're using a 32KB x 8-bit EEPROM and a 32KB x 8-bit static RAM. So you can't actually have 60KB of ROM. I would suggest you simply split the memory map, i.e., the first 32KB be RAM and the rest is EEPROM. If you replace the CD4002 with a 74HC30, you can carve out a single page (256 bytes) for I/O and use the 74HC138 for 8- 32-byte wide I/O decodes. You would also add a 74HC00 to quality a read and write signal for RAM/ROM (and decode). For more detail , consider looking at Daryl's SBC2:

http://sbc.rictor.org/info2.html

I'd also lose the W65C51 due to the hardware problem. If you are set on a 6551 type device, look for a NOS Rockwell R65C51, otherwise consider one of the Philips/NXP UARTs.

Also ensure you have all of the proper 65C02 lines pulled high via pull-up resistors, i.e., RDY, IRQ, NMI, RES, BE, SO. Here's a circuit that does that along with dual Reset (active high and active low) and a NMI trigger.

_________________
Regards, KM
https://github.com/floobydust

Umm, this is a new thread but it's a design that's been introduced in a previous thread. So, BDD and floobydust, you may be missing some context.

Rather strange first build

It's true though that a 32k ROM can't hold more than 32k of data!

Ooooooh very good catch on the size of the EEPROM. I can't believe I didn't catch that already. I do have 53kB of data to store, plus I need some room for program code, so I really do need that much ROM. I can be a little loopy the days following chemo. Those anti-nausea meds are bit methy. I apologize in advance if you see my posts start to get strange about every 3 weeks.
I should have linked my first thread to show the reasoning behind this strange memory map, for this special purpose, non-interactive machine. It's going to be in a display case outside my office, running a loop of the SL train animation out the UART. An RPi will be the receiving end and of the UART transmission and performing the output to a terminal on the monitor. I'm aware of the transmit bug in the W65c51. I saw there's a workaround using a 6522's T2, but I feel that is overkill for this application. Since I'm just going to be reading a byte from an array in ROM, and placing it in the transmit register on the 6551, increment ROM address and repeat, then do the whole thing over again, I can tune up a reasonable number of NOP's to make it work smoothly. It'll never receive anything from the UART, and it will never do anything other than this loop. This will not be a general purpose machine. If I ever want to make it more general purpose, or come up with another idea that maybe interacts with people through the glass via bluetooth or xbee, I'll tear it apart and rebuild it using a more sane memory map and probably add a 6522 for more versatility in communications to the outside world, as well as gaining some really handy timers.

Yeah, I didn't like the speed of the CD0002 either, but wasn't able to find any other 4 input NOR gates, nor did I like the 2-input NAND substitutions for it. It was part of what pushed me to use 74AC parts instead of 74HC parts, even though I know that minor speed difference doesn't put a dent in how much time i'm losing with the CD4002. So it looks like I need to find another solution for my ROMSEL. If any of the top 4 bits are lit, then I'm ROM, if not, then I'm RAM or IO. Maybe a 2-input HC NAND substitution for a 4-input NOR will be faster? or some other substitutions in HC will be faster? I saw how deep the cascading was getting on these substitutions and thought that we could be approaching CD4002 delays with much more wiring anyways.

I'm planning to leave this on a solderless breadboard if it works alright like that so you're note about 74AC not working well will certainly be headed. I'll get HC parts. If I HAVE to, I'll solder up on protoboard, but I'd like to avoid the work if possible considering this is just a display piece, and a solderless breadboarded item, if done neatly, will draw a bit more attention than just another circuit board in a display case in an engineering department.

There's a to digest here. I see where I made some rather serious reading issues on the primer's very basic whole computer schematic and I think I misunderstood some things about the cycle and the timings on the laughtonelectronics timing page. I'll go back to those references and try to tie all this together with your suggestions.

To be clear, whatever logic for the decoding should always be enabled, correct? Otherwise if the won't be ready for their cycle, right? So always having the ROM decoder enabled was good, but disabling the 138 was bad. It's OE's being controlled by the PHI2 that will time the usage of the Data bus, and the read/write qualification to coordinate if the device should be reading or writing. I did get the CE and OE on the ROM being tied together from the primers whole computer schematic but I can also see what you're saying about allowing the bus to settle.

Do you have any suggestions on decoding the ROMSEL(bar)? If I switch to CD74HC4002 that looks like it will be way faster than the CD4002. Definitely shouldn't reach the potential max delays of the CD4002. I'm not sure why I didn't find this part in my search before

Using the Product Index search function on Digikey's web site I discovered that 74HC4002 is a thing, and they're in stock in through-hole and surface-mount. Edit: oops, now you mention the 'HC4002. I think you edited your post as I was typing mine.

Since you're transmitting only -- no receiving -- then you could reasonably omit the UART and achieve the function via bit-banging (ISTR that Gordon touched on this point). Yes the timing's a bit tricky, but certainly manageable. Being transmit-only makes things a lot simpler.

-- Jeff

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

in working out the ROM issue, and needing 2 ROMs to make this work, I'm finding that a 3-input NOR, such as the sn74HC27 MIGHT fit my needs better, as I can then generate ROMLSEL and ROMHSEL signals to enable the upper or lower ROM. So I think I'm jumping the gun on the questions about the NOR gate stuff right now until I try to work out those details a bit more on my own to correct my ROM error and multiple other timing and logic errors. I'll post back once I try and figure those out some more and have a system that I think will work.

I thought about bit banging the UART, but then I feel like I'm getting into a much fancier timing system to solve with NOPs than just figuring out how many NOPs I need in my loop to make sure the W65c51 has sent its byte, but not so many that the animation lags excessively. There's really only one place in code I need to tune the NOPs for my solution, whereas I think there's going to be a lot more places in code that tuning is involved to bit bang UART. I do have an R6551P variant kicking around that I could use if I really need to throw in the towel on the WDC part, but I'd rather start by just using the WDC part and putting in some NOPs in that one spot they will be needed in the loop. The RPi is buffered, and my speed will be 19200baud so the RPi should never fill its buffer, so really its just tuning the number of NOPs in that one spot to get my bytes as close to each other as I can without stomping the register before the 6551 got that byte out. I can use a scope or an LA to see how close my bytes are so that I can see what the space is between them. I really don't think that W65c51 is actually going to cause me a problem in this bizarre application where it does nothing but constantly send bytes and does absolutely nothing else. Its just a byte spitter appliance that spits the same exact bytes in the same exact order all day long. My design certainly has much bigger problems than the hardware transmit flag bug in the W65c51, as floobydust and bigdumbdinosaur pointed out. Unless there's another really serious hardware bug other than the transmit flag issue that everyone is talking about, I really think the WDC part's bug will be easier and simpler to work around than any of the other solutions I'm seeing. It is that transmit flag issue that you are all talking about right? I can see everyone's concern about that hardware bug though, as in most applications I suspect it would cause much more work to deal with and would warrant these other either more hardware intensive fixes, as you would be doing much more general purpose work with an unpredictable UART transmissions at arbitrary times. My rather bizarre setup for a rather bizarre use-case is throwing everyone off, understandably. Its changing the criteria so that some of the things we would normally worry about are not that big a deal. That strangeness is what actually drew me to the build, as I don't really have any purpose for a general purpose 6502 based computer in my department at the moment. I just want to gauge how much interest this device gets to see if I can get any student interest in retro computing projects. Maybe something on a breadboard in a case, making a train animation, will spark some interest and questions about it and we will make a student project to build another general purpose one, that would need to take heed of all these bugs and normal constraints. Honestly I would probably use a 6522 and SPI a MAX3100, or some other more modern UART, and maybe have them put their FPGA skills to work to make a VGA or other more modern video interface out of our Xilinx Artix-7 powered NEXYS 4 boards. For me, I'm just making an appliance as simple and single purpose as possible to set in a case to see if it sparks interest in retro computing.

I agree you can sidestep the problem, but you'll still need to invest design time and materials to get the chip installed and working.

Remember, BTW, that the bit-bang code could be contained in a subroutine -- just a tidy little package that you call for each byte to be transmitted.

Likewise, for delay timing (both in the bit-bang and generally throughout the program) varying the number of NOP's may be a bit awkward. Instead you'll want a loop that decrements X (for example) and tests the result, branching back to reiterate until it finally equals zero. (Maybe that's what you meant.)

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

Well, based on your required memory map, I would suggest you implement a PLD to handle it. With a single glue chip, you can get the desired memory map (RAM, ROM and I/O) along with qualified read and write signals for memory (and non-65xx I/O devices) access. I would also suggest switching to a different UART and avoid writing workaround code as well. The PLD option will give you a flexible memory map which can be changed easily without a hardware design change.

Note that my C02 Pocket SBC was implemented this way with a Philips/NXP SCC2691 UART.

_________________
Regards, KM
https://github.com/floobydust

I'd recommend you add up the propagation delays of the gates you believe you need and compare it to your cycle times. If you're only running a 1 or 2 MHz you're probably fine. All the talk about minimising the number of logic levels is coming from efforts to build 14 MHz systems.

And I think I'd advise you stay away from bit-banging. Keep it simple - you know your application!

What i'm thinking, in pseudocode for now:



Is there a reason that the number of NOPs would need to be drastically different from loop iteration to loop iteration? Shouldn't this be pretty deterministic, or about as deterministic as something that uses UART can get? There's no user input, or anything firing interrupts, to disrupt my loop as far as I can see, the RPi is buffered and at 19200 is unlikely to fill its buffers since its also locked in the case and not being used for anything else. If the Pi decides to do some linuxy maintenance crap once in a rare while and the animation chops for a few minutes a week, its not a big deal. Am I missing something big here like I did with my decoder logic?

floobydust said:


You know, I was just looking at CPLD's since we have all the hardware I need at work to program them already. We use them in some courses. It would save a lot of wiring mess on the breadboards and probably be the easiest with this rather bizarre memory map.

Yes, I would think a constant delay for timing will be fine. You can work it out from the bit rate - if you have a scope or can rig up a divider to flash an LED you'll be able to see what the timing is. If the number of NOPs is excessive just put together a loop or a couple of nested loops - it's a standard tactic.

It might be a close-run thing, but having a countdown to the target number of bytes might be simpler than comparing the pointer. Maybe easier to understand too. Again, it's relatively normal, but either way will work.

All your pointers and increments and decrements will be on 16 bit quantities so you'll need to pick up the idioms for acting on pairs of bytes - again, it's very standard. Perhaps have a read of the easy6502 tutorial. There's a huge amount of fine detail to programming the 6502 perfectly which you just won't need for this.

BigEd, yeah I like that countdown method better. I'm just going to have to get used to working with high byte and low byte, whereas with CortexM I really never needed to worry about that unless I was assembling bytes into larger datatypes I got from I2C devices or UART.

I have access to 200MHz logic analyzers and 100MHz scopes at work, so I should have all the measurement equipment I need to see how close the output bytes are. They don't have to be perfectly right up against each other, but they don't need to be miles apart either.

And yeah, I might break out the NOPs into a another nested loop instead of having 200 lines of NOP, for example.

To be clear, its the transmit bit bug everyone is concerned about, not some other bug I don't know about, right?

Indeed. The status bit for 'space in the transmit buffer' is stuck at 1. Apparently it's not possible to use IRQs either. So you have to dead-reckon. As you say, you don't even have to be accurate, you just lose a little throughput.

Two-byte operations are no problem! Generally you act on the lower byte first then maybe do a test and then maybe act on the high byte.

Well, I already implemented a delay timing workaround when I discovered the Xmit bug some years ago. You can reference it here:

viewtopic.php?f=4&t=2543&start=30#p29795

Just change a couple parameters for the baud rate and CPU clock rate and you're good to go.

_________________
Regards, KM
https://github.com/floobydust