Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

jbaum81's Achievements


Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Week One Done
  • One Month Later

Recent Badges



  1. Any luck getting the PS2 working with the VIA's @ 8mhz ?
  2. So out of curiosity, why not just design an expansion card and stick it straight on the data / address bus? There is plenty of space in the IO area for the chip and something like the SC28L92 only has 4 registers lines so technically it could fit into half of one of the available expansion ranges. This is the chip I chose for my project and I intend on using it with the X16 as well once I get mine
  3. Yup, that's essentially what I'm doing, just using just switched out the logic in the SPLD to trigger the clock pin on the latch on the falling edge.
  4. DANG IT!!! Found the last issue, Labeled the RW pin RWB in on the main sheet and RW in the logic sheet. Had to run a bodge from the RW input on my PAL to RWB net and now the board runs stable at 15Mhz!! woot!! Already started the 2nd revision with a few other enhancements like an LED array to show activity on the devices. It will be helpful when running slow and a cool light display when running full out.
  5. Nope, I cooked the Oscillator , I must have hooked something up backwards, Ordered a new 8mhz oscillator and it's fine. Also figured out the issue with the flipflops on the banks. I was sending the clock signal to the flipflops when the address was set and clock went high, but for some reason the datelines were not ready fast enough, which doesn't seem consistent with 65c02 data sheet?!?. None the less I changed the programming of the PAL to send the clock pulse to the FlipFlops on the falling edge instead, where I could tell the data and address is held at least for a few NS. This did work, but does have the negative effect of sending two clock pulses per cycle to the flipflop but even if it does mess up the address lines for the ROM/ HiRAM it's okay since the lines are set right at the completion of the cycle prior to any attempt to read / write from ROM/HiRam. Incidentally I did order a couple SST39SF040's ROM's which are rated at 70NS, and was able to run the clock up to 14.75MHZ overnight and was stable. 15mhz did produce some corruption haha. This is on a breadboard so the theory is that on the printed board it should be awesome at 8mhz... But wait, not so fast!! I did order up a batch of boards, I did forget the pullup resistor on the reset line .. Can't find any other issues with the board, but it doesn't run :(. I'm using Ben eaters Arduino monitoring and it looks like data lines are floating ?? I pulled the PAL's ran a more simple addressing scheme (Ben's) through some NAND gates jumped over on a breadboard and it was stable. Running a much much slower clock I'm on occasion able to get it to behave for a while just flashing some LED's back and forth on the 65c22, but it's by no means stable. Thinking I screwed up the board I soldered up another and same stuff. It's a 4 layer board with really small traces that go between pins so I'm worried something may have gone wrong somewhere there. Need to run through the logic chips and check for continuity issues maybe with an address line somewhere? I'm really not sure at this point, I can't find anything wrong in my CAD software. If anyone is interested in providing an extra set of eyes, I have no issues sharing my files, just PM me. I'll update back when i find the issue.
  6. Think I may have figured it out, the wave goes from ~2.5v to 5.0v, this is the device I got, says hcmos/ttl format. Not sure if it's bad or I'm misunderstanding something, but I never get 0 logic levels so that's probably why it isn't running it. Can't take a picture right now, phone is dead. I'll follow up tomorrow. https://www.mouser.com/ProductDetail/774-MXO45HS-3C-8.0
  7. Well I decided to go with some PAL's to clean up the addressing logic, it runs for hours at 11mhz on the breadboard, and only a few minutes @ 12mhz. The data lines get an occasional weird artifact on high, but the address lines look pretty good, there is some small artificating here and there but doesn't seem to cause any issues, and may well be the cheapish scope.. The ROM is only 70NS so it's surprising it runs at all at 12mhz, with address setup time that's 100ns, in an only 83ns cycle. I did enable the rom on low clock to try to squeeze some extra performance out of it, all other OE/Write's are done on the rising edge of the clock. The flipflops do set the outputs low on reset, but I'm having trouble latching them, I get random results, not sure, but I think I may have fried them. I need to pull them out of the circuit to test them by themselves. Also strangely enough, I bought a 8mhz crystal and it says it's a hcmos output, but the wave looks like a shark tooth and my computer wont run with it, but using the wave generator I've had it running all the way up to 14mhz, although not very stable. The wave at 11mhz on the signal generator isn't very square, but it still works. Trying to figure out why the 8mhz oscillator doesn't..... Should I be shooting for something that produces more of a square wave, or is that even possible at those speeds? Or maybe my scope lacks the resolution??
  8. So much to learn and so little time haha. At least I can say it's a hell of a lot cheaper of a hobby than my previous reef keeping or RC Helicopter hobbies. I'm thinking it might be time to retire the old DSO nano scope and move into a benchtop 2 channel scope. I can't believe how cheap it is to have boards printed now. Last time I had a board done was about 10 years ago and you had to join in on a group buy type thing and wait till the board was filled and printed in china. Took like 6 weeks.
  9. Almost positive he mentioned the vera needing writes on high clock, and im thinking the audio chip, but simce none of the tests were working im thinking there might have been a yiming issue woth the rom. I dont remeber the specifics as it relates to the cx16, but it motivated me to try to read and understand the data sheets. Ben Eater also has some pretty good material on understanding it. My main take away was to attempt to have address and and data stable prior to writes, the 6502 doesnt seem as sensetive on reads as long as its stable by, iirc, something like 30ns from the falling edge.
  10. I think I was under the assumption that eventually the signal levels would reach 0 or 5v and that'd be totally okay given the amount of time, of course this would be predicated on stable power, right? I'll definitely look into alternatives, but finding low propagation delay logic gates has been somewhat challenging. As for running RW through the grounded input on the low address range F521, it's definitely a good idea, and would work, but I'm using the CLKWR signal out of that AND gate for write enable on the ram chips anyways. I don't think it's required, but I do have the time and wanted to try to make sure all address and select logic is taking place on low clock, with writes only occurring during high clock. I got lazy and didn't give the same consideration for reads, but meh, not really necessary, at least as far as I can tell. Trying to learn, the best I can, from my understanding of the mistakes Adrian pointed out on the 2nd proto board with timing. As an aside, I just updated my PCB layout and seen all the logic IC's and their associated rats nests drop into my, so far, beautifully laid out board and traces. I admit, I leaned back in my chair and started wondering why in the hell I'm trying to do this all through hole lol. I may just scrap my progress and switch to SMD. If I can figure out how to program the ROM while it's soldered onto the board I may switch to SMD and try to shoot for some faster RAM/ROM chips and maybe shoot for 12mhz.... Oh I think I could use a clock divider and leverage another flipflop in the IO area to change the speed on the fly. I think that'd be kind of fun.
  11. I started this adventure to build my own 6502 computer inspired by Ben Eater's video's. After I did that and wrote a little assembly I sort of decided that I didn't want to be on an island by myself and decided I'd maintain compatibility with the CX16. This way I get the experience of designing my own circuits (Note I have not asked for yours), and mine would be compatible with your software. To be clear I absolutely 1000000000% plan on supporting this project and will purchase a CX16 once released, but ultimately would like to run my own board that way I'm familiar with the hardware and able to support it myself. Soldering chips to someone else's design doesn't quite tickle my fancy lol. Also I did email David about this, not necessarily to ask permission, but he is aware of what I'm up to and didn't take any issue with it. If I'm oversharing or offending anyone on the project please let me know, obviously my interest isn't to 'clone' it in any way to undermine or hurt the project. Apologies, I was actually referencing the programming guide on GitHub, sorry for the confusion. As for mixing logic, are you referencing the differences between TTL and CMOS? Most I could find on those is the voltages considered high/low, which, as far as I understand, shouldn't really make any difference in my logic? Can you clarify or point me in the right direction as to what makes them incompatible? Thanks for the pointers, I'll check into that.
  12. I think I found my solution!!! Using some 8 bit comparators. All logic is >= 10ns at each phase. I think my only gap here is the flip-flop for the rom. I think I need to hold OE high with some pull down resistors on it's outputs to keep the rom on bank 0 for boot. Was thinking maybe a 555 timer tied to the yet to be created reset circuit.... The thought would be to hold RST low during power on with some additional logic to keep OE high long enough to execute an instruction to latch it at 00. Anyone have a better idea for boot?
  13. Gets better, I seen a video going over changes in the 2nd revision and it appears they're completely moving around the IO area as well. Looks as if both Via's will now co-exist at the top of the range. I definitely like those changes, it's a lot more comprehensive. None of it is updated in the wiki.
  14. The datasheet was a little confusing to me. It did say that OE doesn't affect the flipflops, but it does say that new data can be entered or retained while output is in high impedance state (OE high) . I wasn't sure if the output would remain locked to old values if left low, so I decided to take the safe route and bring it high while I latch in the new data. I'd definitely prefer to just tie it to ground though if the output will literally just echo the state of the flipflops as they change. Here is the datasheet for the latch I chose. https://www.ti.com/lit/ds/symlink/sn74f574.pdf
  15. Well, Since input and output are on separate pins it's not to prevent shorts or bus conflicts. It's not really necessary in my use case, I don't think the circuit itself requires it. The only reasons I could think of is for signal stability or the ability to have CP hooked directly to the clock without the need of additional logic there. I opted to apply logic to CP in my case primarily to balance the logic load for select between it and OE.
  • Create New...

Important Information

Please review our Terms of Use